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Decision- Science  Applications,  Inc.  (DSA)  has  created, 
installed,  and  tested  a  system  for  the  Navy  termed  the  Acqui¬ 
sition  and  Logistics  Information  and  Analysis  system  (ALIAS)  . 

This  analyst  information  system  is  used  by  NAVSEA  90  to  improve 
ship  acquisition  planning  so  that  programs  are  on  time,  are 
within  budget,  and  fit  cohesively  into  a  fleetwide  programming 
plan.  ALIAS  provides  the  Navy  with  the  tools  needed  to  help 
identify  poorly  planned  programs  quickly,  and  to  allow  for  quick 
analysis  of  alternative  program  schedules.  It  consists  of  1)  a 
large,  integrated  relational  data  base,  2)  a  menu  command  system 
which  allows  the  user  to  perform  any  task  through  the  use  of  menu 
selection  or  direct  command,  3)  an  extensive  help  subsystem  which 
guides  the  novice  through  the  syst^  or  provides  the  experienced 
user  with  a  quick  reference  guide,  4)  several  libraries  of  util¬ 
ity  procedures,  and  5)  a  varied  of  high  level  analytical  and 
functional  modules  which  interface  with  both  the  command  system 
and  the  data  base.  A  scenario  system  is  «nployed  to  allow  any 
variety  of  '*What  if?"  questions  without  the  need  for  multiple 
copies  of  the  data  base  ensuring  quick  turnaround  with  data 
integrity  and  security. 

1.1  DESCRIPTION  OF  THIS  MANUAL 

This  manual  is  designed  to  familiarize  the  new  user  with 
the  current  capabilities  of  the  ALIAS  system  as  implemented  on 
the  current  host  HP-3000  computer,  to  describe  how  to  exercise 
these  capabilities,  and  to  provide  a  reference  guide  for  the 
experienced  user.  For  a  complete  description  of  the  system 
architecture  and  an  understanding  of  how  the  ALIAS  system  actu¬ 
ally  works,  the  user  is  referred  to  the  companion  volume,  TbP 


The  manual  describes  four  things 


1)  Basic  concepts  you  will  need  to  know. 

2)  How  the  system  works  in  practice.  This  is  communicated 
by  giving  an  example  of  an  ALIAS  session. 

3)  The  logical  details  of  how  various  parts  of  the  system 
work. 

4)  How  to  use  the  various  parts  of  the  system - what 

commands  need  to  be  given,  what  data  is  required,  etc. 

Section  2  presents  all  the  concepts  that  you  will  need  to 
know.  Section  3  presents  a  sample  session  in  a  format  which 
features  what  will  appear  on  screen  or  printer  on  the  right-hand 
pages,  with  running  comments  on  the  left-hand  pages.  You  can 
learn  a  lot  about  how  to  use  the  system  just  by  looking  through 
Section  3. 

Section  4  describes  how.  to  operate  the  ALIAS  Command 
System.  Sections  5-7  describe  the  role  of  the  ALIAS  data  base 
and  how  to  access  and  modify  it.  Sections  8  and  9  describe  the 
applications  modules  which  ALIAS  currently  offers. 

ALIAS  outputs  are  described  as  the  discussion  goes  along. 
One  of  the  characteristics  of  the  system  is  that  the  format  and 
content  of  any  given  output  can  vary  widely  (under  your  control) 
so  it  is  impossible  to  present  an  exact  and  complete  set  of 
system  outputs.  If  you  want  to  see  some  sample  outputs  right 
away,  turn  to  Section  3  or  Sections  8  and  9  and  look  for  Figures 

1.1.2  Related  P^iblicfttigps 

To  find  out  more  about  the  HP  3000  computer,  see  tlsipg  the 
2QQQ  r  ilSlDfl.i'lljRSf  ia£S.£Qmsii^  f  and  the 
fjianual .  all  by  Hewlett-Packard.  To  find  out  more  about  the 
RELATE  ISMS,  see  Introdupti-gP, RBLATf  and  the  RELATE. Bgf gf engg 
gianual  (the  CREATE  and  GRAF  manuals  may  also  be  useful)  ,  all  by 
Computer  Resources,  Inc.  (CRI) . 


The  ALIAS  MfliJitfiJiaJXCfi-gJJddfi  describes  the  actual  ALIAS 
software  structure  (considerably  more  complex  than  it  may  appear) 
and  the  details  of  how  it  works.  A  knowledge  of  programming  is 
required  to  fully  understand  the  Maint^nai><?^  qujde.  but  non- 
progreunming  users  curious  about  the  software  can  learn  a  lot  by 
reading  the  first  several  sections  of  that  manual. 

1.2  DOCUMENTATION  STANDARD 

The  set  of  ALIAS  Guides  pay  attention  to  but  do  not 
strictly  follow  the  DoD  Automated  Data  ^sterns  Documentation 
Standards  (7935.1-S,  September r  1977) .  The  set  of  manuals  exceed 
the  standard  in  terms  of  information  content,  and  each  is 
organized  somewhat  differently  in  order  to  make  them  more  useful 
to  ALIAS  users  and  maintenance  personnel.  If  you  are  accustomed 
to  reading  documentation  according  to  the  standard,  you  may  see 
Appendix  A  of  the  Maintenance  Guide,  which  cross-references 
sections  mandated  by  the  standard  to  sections  of  this  ALIAS 
documentation. 

1.3  WERVIEW  OF  ALIAS  STRUCTURE 

Hie  design  goals  for  ALIAS  software  are  ease  of  use,  high 
user  control  of  system  operations,  output  consistency,  flexibil¬ 
ity,  and  expandability. 

As  an  analyst  or  manager,  you  cannot  be  more  productive  if 
your  software  tools  are  difficult  to  learn  and  use.  On  the  other 
hand,  you  cannot  be  more  effective  if  they  are  so  simplified  that 
they  cannot  handle  the  range  of  situations  you  face.  There  is 

typically  a  tradeoff  in  software  between  control  and  usability - 

ALIAS  software  circumvents  the  tradeoff  whenever  possible, 
choosing  to  give  you  control  if  forced. 

ALIAS  minimizes  inconsistency,  which  usually  results  from 
the  use  of  different  underlying  data,  by  using  a  single  inte¬ 
grated  data  base  for  everything.  However,  ALIAS  is  not  limited 
to  only  one  study  (i.e.  one  data  set)  at  a  time.  There  can  be 
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multiple  data  base  partitions  (i.e.  studies  or  scenarios)  current 
at  once.  But  any  single  scenario  is  always  internally  consistent 


Any  tool  must  be  flexible  enough  to  accommodate  the  range 
of  situations  you  faced.  ALIAS  is  a  modular  system^  cdlowing 
selection  and  combination  of  the  tools  appropriate  to  any  task 
(with  no  requirement  to  step  through  irrelevant  sequences)  . 
Further,  the  individual  modules  typically  have  a  variety  of  mode 
options  ("switches”)  which  can  be  set  to  customize  their  oper¬ 
ations  for  a  given  task. 

You  will  doubtless  encounter  problems  you  know  ALIAS  could 
help  you  with  ("I  need  the  delivery  dates  of  all  ships  planned 
for  construction  in  states  with  a  population  of  X  million  or 
more,  by  state"),  but  for  which  no  specific  software  exists.  The 
dynamic  query  capabilities  offered  by  ALIAS'  DBMS  often  make  it 
possible  for  you  to  construct  appropriate  software  quickly  by 
yourself.  For  more  complex  tasks,  the  internal  design  of  ALIAS 
and  the  support  offerred  by  the  ALIAS  environment  will  help  your 
programmers  create  the  solution  quickly. 

Once  a  solution  is  created,  it  can  be  permanently  added  to 
the  stock  of  ALIAS  tools  (and  made  publicly  available,  if 
desired)  with  relatively  little  effort  (a  familiarity  with  the 
material  in  the  Maintenance  g^iide  is  required  to  do  it  reliably, 
but  given  the  familiarity  the  job  can  usually  be  done  in  an  hour 
or  less)  . 

ALIAS  software  is  structured  in  a  large  number  of  pieces 
which  work  in  concert.  The  pieces  can  be  categorized  in  a  number 
of  ways;  in  this  manual  two  approaches  will  be  used.  Figure  1-1 
presents  the  first,  in  which  ALIAS  is  presented  as  being  composed 
of  two  basic  parts:  a  data  base  with  DBMS  and  a  block  of 
analysis  software.  The  analysis  software  requires  the  data  base 
as  a  source  of  inputs  and  (sometimes)  as  a  repository  for 
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Figure  1-1.  Acquisition  and  Logistics  Information 

and  Analysis  System  Software  Architectiure 


outputs.  The  data  base  requires  one  of  the  modulesr  the  Data 
Base  Updating  System,  if  its  contents  are  to  be  current  and  con¬ 
sistent.  Both  the  data  base  and  the  analysis  software  can  be 
further  broken  down:  the  data  base  into  groups  by  subject,  and 
within  groups  into  individual  tables  of  data;  and  the  analysis 
software  into  individual  modules  which  perform  specific  tasks. 

The  data  and  the  programs,  then,  can  be  thought  of  as  fairly 
separate  entities  which  are  still  crucially  dependent  on  one 
another. 

A  similar  presentation  of  structure  is  given  in  Figure  1-2. 
This  one  is  more  relevant  to  day-to-day  ALIAS  use.  You  will  make 
use  . of  ALIAS  in  two  basic  ways:  by  running  the  Core  command  sys¬ 
tem,  and  by  running  the  DBMS.  The  Core  command  system  is  where 
you  choose  among  analysis  modules.  It  is  also  the  gateway  to  use 
of  the  Data  Base  Updating  (DBU)  system,  which  you  are  likely  to 
use  a  lot. 

Even  if  you  never  do  data  entry  as  such,  the  DBU  provides  a 
way  to  find  and  inspect  individu£d  data  base  items,  and  to  make 
modifications.  ALIAS  analysis  software  is  typically  very  "data- 
driven"  (part  of  the  high-control  philosophy) ;  one  of  the  ways 
you  can  make  it  handle  specied.  cases  is  by  changing  data  base 
values.  For  example,  you  can  examine  the  impact  on  deployable 
battle  groups  of  changing  the  official  carrier  retirement  sched¬ 
ule  to  some  cdternative  by  changing  the  official  retirement  dates 
in  the  data  base.  You  can  do  this  without  destroying  the  of¬ 
ficial  data  or  disturbing  anyone  else's  work.  Changing  a  dozen 
dates  can  be  slightly  tedious,  but  not  nearly  so  tedious  as 
having  to  compute  the  force  structure  by  hand  because  software 
doesn't  let  you  change  the  underlying  data. 

The  scenario  manager  (or  more  precisely,  the  scenario 
orientation  built  into  the  entire  ALIAS  structure)  is  what  lets 
you  change  those  retirement  dates  without  affecting  anyone  else. 
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Think  of  a  scenario  as  being  your  file  drawer  in  a  filing  cab¬ 
inet,  where  the  filing  cabinet  is  the  data  base.  You  can  be 
changing  the  contents  of  your  drawer  while  your  neighbor  works 
with  hers,  and  her  work  will  not  be  disturbed. 

The  Core  conunand  system's  main  purpose  is  to  present  menus 
listing  the  choices  you  have.  Although  it  does  allow  you  to  set 
the  values  of  "parameters”  (switches)  which  control  the  operation 
of  analysis  modules,  the  command  syst«&  does  not  itself  generate 
any  productive  output.  Learning  the  command  system  is  a  prereq¬ 
uisite  for  working  with  ALIAS:  running  the  command  system  isn't 
what  you  really  want  to  be  doing,  but  you  can't  do  what  you  want 
to  do  without  it.  By  organizing  things  this  way  your  work  as  a 
whole  goes  faster,  because  the  command  system  invisibly  handles  a 
lot  of  overhead  work  for  you. 

The  second  basic  means  of  using  ALIAS,  by  running  the  DBMS, 
is  for  making  ad  hoc  queries  and  for  creating  new  reports.  The 
DBMS  gives  you  direct  access  to  the  data  base  files,  allowing  you 
to  combine  and  consolidate  information  using  relational  methods, 
which  are  very  flexible.  However,  you  will  not  be  edlowed  to 
change  data  base  data  through  the  DBMS,  only  through  the  DBU. 
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2  .  0  C^EJ^^_AND  TERMINOLOGY 

This  Section  will  present  the  major  software  concepts  you 
need  to  understand  in  order  to  use  ALIASr  and  will  also  define 
some  of  the  terms  used  in  the  rest  of  the  manual.  The  Section  is 
organized  as  an  alternative  introduction  to  the  structure  of 
ALIAS;  the  concepts  and  terms  are  set  off  to  make  it  easier  to 
refer  back  to  them  later.  Concepts  and  terms  are  in  bold  face; 
major  definitions  are  in  single** spaced  indented  paragraphs. 


The  Section  is  likely  to  be  difficult  to  read  straight 
through  because  it  presents  many  abstract  ideas  and  rules  with 
almost  no  examples.  We  suggest  that  you  glance  through  the 
Section  to  get  a  general  idea  of  what  it  offers,  reading  the 
summary  at  the  end  closely.  Then  go  on  to  Section  3  (the  sample 
session)  for  examples.  Turn  back  to  this  Section  and  read  the 
relevant  paragraphs  (easily  found  using  the  alphabetical  list  in 
section  2.1)  as  necessary  as  you  read  the  rest  of  the  manual. 


Mote  that  you  are  assumed  to  be  familiar  with  the  terms  and 
concepts  of  ship  acquisition  program  analysis. 


2.1  ALPHABETICAL  LIST  OF  TERMS  AMD  CONCEPTS  WITH  PAGE  NUMBERS 

ABORT  command  3 
arrow  k^s  4 
BACKSPACE  key  4 
BREAK  key  3 
choices  8 
commands 
context  7 
control  key  3 
control-q  3 
control-s  3 
control-y  3 
core  5 

CTRL  key  ~  see  control  key  3 
cursor  3 

cursor  control  keys  4 
data  6 
data  base  4 

data  base  management  system  4 


data  base  structure  4 

DBMS  —  see  data  base  management  system 

defaults  8 

DEL  key  4 

direct  access  12 

display  3 

editor  12 

environment  8 

field  name  10 

fields  10 

file  name  7 

files  6 

format  control  file  12 

gate  13 

group  7 

help  13 

hierarchy  9 

host  computer  2 

HP  —  Hewlett-Packard  3000  computer  2 

indexes  10 

indirect  access  12 

instructions  6,8 

join  11 

key  10 

key  fields  10 
keyboard  3 
LISTF  command  3 
log  on  4 
menu  7,8 
modules  5 

MPE  - —  see  operating  system  3 

on-line  help  13 

operating  system  3 

outputs  6 

page  8,9 

paging  9 

parameter  13 

peripheral  files  5 

peripheral  processors  6 

primary  key  10 

privileges  12 

processors  6 

prompt  7 

PURGE  command  3 

records  10 

relation  9 

RESUME  command  3 

RETURN  key  3 

scenario  11 

scenario  structure  12 

screen  8 

settings  8 


SHOW JOB  command  3 

structure  — -  see  scenario  structure  or  data  base  structure 

system  4 

system  core  5 

termincd  2 

text  editor  12 

2.2  THE  COMPUTER 

ALIAS  is  composed  of  software  running  on  a  general-purpose 
minicomputer,  the  "host": 

HOST  COHPUTBR:  The  computer  that  ALIAS  runs  on.  Currently  the 

host  is  a  Hewlett-Packard  3000  (HP  3000  or  HP  for 
short)  located  at  the  offices  of  PMS  392.  You 
will  need  to  know  the  basics  of  using  an  HP  3000 
in  order  to  use  ALIAS. 

You  will  access  this  computer  using  a  terminal,  a  device 
with  a  keyboard  and  a  TV-like  screen.  The  screen  will  be 
referred  to  in  this  manual  as  the  display.  As  you  type  things 
on  the  keyboard,  a  blinking  white  box  or  uaderbar  on  the  display 
will  move  along,  leaving  symbols  in  its  wake.  The  moving  marker 
is  called  the  cursor;  it  indicates  "where  you  are"  on  the 
display. 


The  terminal's  keyboard  will  have  several  keys  in  addition 
to  the  standard  letters  and  numbers  to  be  found  on  a  typewriter. 
Among  the  most  important  is  the  RBTOSH  or  carriage  return  key. 
Hitting  this  key  gets  the  computer's  attention,  telling  it  that 
you  are  ready  for  it  to  process  what  you  have  been  typing.  Also 
important  is  the  BREAK  key,  usually  located  at  the  upper  right 
hand  corner  of  the  keyboard.  Hitting  this  key  tells  the  computer 
to  stop  whatever  it  is  doing  and  return  you  to  the  operating 
system. 

OPBRATIHG  The  operating  system  is  the  host  computer's 

SYSTEM  :  supervisory  progr^un.  It  is  in  control  of  all  of 

the  HP's  resources;  its  function  is  to  eULlocate 
them  to  users  and  to  ensure  that  no  user  disturbs 
the  work  of  another.  On  the  HP  the  operating 
system  is  known  as  "MPB",  which  stands  for 
"Multi- Prog ramming  Executive."  You  can  tell  you 
are  at  the  operating  system  "level",  i.e.  you  are 
talkino  to  it  directly,  when  the  computer  types  a 
":"  and  waits  for  you  to  type  in  a  command.  There 
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ace  many  operating  system  commands  you  can  give* 
Among  the  most  useful  are  LIST?  to  list  the  files 
you  have,  P0B6E  to  delete  a  file,  and  SHONJOB  to 
find  out  who  else  is  using  the  computer.  See  HP's 
manuals  to  find  out  more  about  MPE. 

When  you  see  the  prompt  after  hitting  the  BREAK  key  you  may 
give  the  "ABORT”  command,  which  will  permanently  terminate  the 
program  you  were  running.  If  you  want  to  go  on  with  what  you 
were  doing,  you  may  type  "RBSONS". 

Another  important  key  is  the  control  key,  likely  to  be 
ladseled  "CTRL"  and  located  at  the  left  middle  of  the  keyboard. 

The  control  k^  can  be  thought  of  as  a  sped  ad  sort  of  SHIFT  key. 
It  makes  other  keys  mean  things  they  don' t  usually  mean,  just 
like  the  shift  k^  can  make  the  "1"  mean  "1". 

There  are  three  particularly  useful  things  you  can  do  using 
the  control  key.  If  something  is  being  typed  out  on  your  display 
that  you  really  don't  want  to  see,  but  you  don't  want  to  go  so 
far  as  to  abort  the  program  that  is  typing  it,  you  may  hold  down 
the  control  key  and  the  "Y”  key  simultaneously  (referred  to  as 
"CTRL-Y"  or  "COHTROL-Y") .  In  most  (not  all)  cases  this  will 
cause  the  rest  of  the  output  to  be  thrown  away. 

If  you  want  to  see  all  of  what  is  being  typed  but  it  is 
going  too  fast,  you  can  use  "CTRL-S"  to  temporarily  stop  the 
output.  When  ready  you  can  type  "CTRL-Q"  and  output  will  resume 
where  it  left  off. 

Your  keyboard  is  also  likely  to  have  some  cursor  control 
keys  or  "arrow"  keys  and  a  DBL  or  "delete"  key.  These  will  not 
work  properly  with  ALIAS  programs.  They  will  move  the  cursor 
around  the  disple^  in  most  cases,  but  the  programs  will  not  "see" 
what  you  see  when  you  finally  hit  the  RETURN  key.  Do  not  use  the 
arrow  keys.  The  BACKSPACE  key  (upper  middle  right  area  of 
keyboard)  will  work,  though. 
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In  order  to  use  ALIAS  or  any  facilities  of  the  host  com¬ 
puter  r  you  must  be  logged  on.  Logging  on  is  a  process  whereby 
you  identify  yourself  to  the  c<mputerr  are  recognized  as  a  valid 
user#  and  are  assigned  resources  to  work  with.  See  the  beginning 
of  Section  3  for  guidance  on  how  to  log  on. 


Throughout  this  manual  the  term  system  will  be  used  often. 
In  some  sense  it  will  alw^s  refer  to  the  same  things  that  being 
the  combination  of  the  host  computer  and  ALIAS  software,  but  the 
references  will  be  at  many  levels  of  aggregation.  For  example, 
ALIAS  software  is  composed  of  roar^  semi- independent  pieces  of 
software,  some  of  which  can  be  referred  to  as  systems  in  their 
own  right.  Whether  the  word  "system”  is  referring  to  part  or  all 
of  ALIAS  should  alwc^s  be  clear  from  its  context. 


2.3  SYSTEM  BUILDING  BLOCKS 

Think  of  the  software  portion  of  ALIAS  (which  is  what  this 
manual  is  exclusively  concerned  with)  as  residing  in  or  on  top  of 
the  HP  hardware  and  the  MPE  operating  system.  The  software  uses 
six  major  building  blocks:  a  data  base,  a  data  base  manage¬ 
ment  system  (DBMS) ,  a  System  Core,  modnles,  peripheral  files, 
and  peripheral  processors. 

DATA  BASS  :  The  ALIAS  data  base  holds  a  description  of  part 

of  the  real  world,  in  particular  of  ship 
acquisition  programs  and  the  resources  needed  to 
carry  them  out.  When  you  use  ALIAS  you  are  almost 
always  drawing  on  this  world  description  and/or 
are  changing  it  to  be  more  up-to-date  or  to  suit 
your  purposes.  The  data  base  can  be  divided  into 
two  parts  conceptually:  one,  the  structure,  is 
the  repository  or  vessel  in  which  the  data  is 
kept;  the  second  is  the  data  itself.  The  term 
"data  base"  will  usually  refer  to  both.  It  will 
become  clear  to  you  that  the  data  itself  is 
"living",  constantly  changing,  but  be  aware  that 
the  structure  is  also  quite  changeable.  Should 
you  need  a  repository  for  data  not  currently 
available,  the  ALIAS  data  base  can  be  expanded  to 
handle  it. 
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DATA  BASE  A  DBMS  is  a  supervisor  for  a  data  base.  It  sets 

NAHAGBIIBHT  up  and  maintains  the  structure,  and  provides 
STSTBll  (DBNS)  :  means  of  changing  and  retrieving  the  data.  By 

"buffering*  all  actions  with  regard  to  a  data  base 
through  a  DBMS,  everyone  is  guaranteed  that  there 
is  a  single,  consistent  set  of  rules  for  using  the 
data  base.  ALIAS  uses  the  RELATE  DBMS,  which 
provides  a  query  language,  report  generator, 
graphics  capability,  and  data-entry  form 
management  language.  The  query  language  and 
report  generator  are  most  important  for  an  ALIAS 
user  to  know  about— they  provide  a  set  of  tools 
for  asking  questions  about  the  state  of  the  world 
(i.e.  the  contents  of  the  data  base)  and  for 
receiving  the  answers  in  a  nice  format.  It  is 
important  to  know  that  RELATE  is  a  stapd-a] ppp 
program  on  the  HP;  this  means  it  can  be  executed 
independently  of  the  rest  of  ALIAS.  In  the 
"dumbbell*  representation  of  the  ALIAS  structure 
in  Figure  1-1,  note  that  the  data  base  and  DBMS 
compose  the  entire  left-hand  circle. 


STSTBM  CORE  :  The  Core  is  to  ALIAS  what  MPE  is  to  the  HP  3000; 

a  supervisory  program  which  provides  services  to 
you  the  user  and  which  ensures  that  users  do  not 
conflict  with  one  another.  It  does  little  or  no 
"work"  in  the  sense  of  producing  outputs  you  are 
interested  in.  Its  function  is  to  provide  an 
organized  means  of  letting  you  choose  among  ALIAS 
capabilities.  If  you  have  made  some  use  of  ALIAS 
already,  you  can  think  of  the  Core  as  being 
composed  of  the  Command  System,  the  scenario 
system,  and  the  DBU. 


:  ALIAS  modules  are  processors  which  concentrate 
on  performing  a  particular  function,  usually  an 
analytical  function.  Most  draw  upon  and/or  change 
the  contents  of  the  data  base,  and  most  produce 
some  sort  of  printed  output.  Modules  are  public 
resources  likely  to  be  of  interest  to  a  wide  variety 
of  users.  An  example  of  a  moouie  is  tne  rorce 
Level  Report  Generator,  which  provides  estimates 
of  the  number  of  ships  which  will  be  deployable  in 
future  years. 

You  may  wish  to  develop  your  own  data  bases 
:  as  parts  of  analyses  that  you  or  a  group  of  your 
colleagues  are  Involved  in.  Though  not  actively 
supported  or  supervised  by  ALIAS  system  managers, 
such  data  bases  are  considered  a  part  of  the 
resources  of  ALIAS  as  a  whole.  Similarly,  ALIAS 
s(xnetlmes  expects  to  find  certain  kinds  of 


NODULES 


peripheral 

PILES 


information  in  text  files  which  you  make  up 
independently. 

PERIPHERAL  Similar  to  a  peripheral  file  or  data  base,  a 
PROCESSORS  :  peripheral  processor  is  one  developed  by  an 

ALIAS  user  for  his  or  her  personal  use  or  for  the 
use  of  a  small  group.  Most  such  "processors”  are 
DBMS  report  generation  command  files  (files  which 
cause  a  custom  report  to  be  generated) . 

In  these  last  definitions  some  terms  were  used  which  have 
not  yet  been  defined,  n2unely  "files”  and  "processors." 

The  operation  of  any  piece  of  computer  software  requires 
three  things:  data  to  be  manipulated,  a  processor  to  perform 
the  manipulations,  and  instructions  from  you  the  user  on  what  is 
to  be  done.  Operation  always  results  in  outputs. 

In  ALIAS,  the  data  always  comes  from  the  data  base.  You 
can  always  look  at  the  data.  The  data  is  a  picture  of  the  ship 
acquisition  and  construction  world. 

Processors,  however,  are  generally  somewhat  hidden  from 
you.  You  typically  cause  an  ALIAS  processor  to  go  to  work  by 
choosing  from  among  a  list  of  options  on  a  menu.  You  will  often 
neither  know  nor  need  to  know  much  about  a  processor's  nature. 

ALIAS  expects  you  to  provide  instructions  in  several 
different  formats.  Most  of  this  manual  is  concerned  with  what 
instructions  you  must/may  provide  and  with  how  to  provide  them. 

Outputs  may  either  be  changes  to  the  data  base,  infor¬ 
mation  typed  onto  your  terminal's  display,  or  printed  reports. 

An  analogy  may  help  here.  ALIAS  is  a  productive  system 
which  involves  several  parts,  somewhat  like  your  kitchen.  Say  you 
are  going  to  bake  a  cake.  You  will  first  need  to  take  raw  mater- 
i£ds  from  your  cabinets  (the  flour,  butter,  etc.  are  analogous  to 
the  data  in  the  data  base,  the  cabinets  to  the  data  base  struc- 
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ture»  and  you  are  the  DBMS  in  this  case).  Then  you  will  need  to 
perforin  at  least  two  operations  on  the  materials  (data),  mixing 

and  baking.  Your  mixer  and  your  oven  are  like  processors - they 

act  on  the  materials  (data)  but  are  themselves  unchanged  when  the 
actions  are  completed.  Your  instructions  are  the  speed  at  which 
you  set  the  mixer,  your  pushing  of  its  on  and  off  buttons,  and 
your  setting  of  the  oven's  temperature  and  timer.  Notice  that  the 
precise  way  in  which  you  give  the  instructions  depends  on  the 
nature  of  the  appliance  (processor).  Notice  also  that  the  out¬ 
put,  the  cake,  might  be  placed  back  in  a  cupboard  (analogous  to 
outputs  going  back  into  the  data  base  rather  than  to  a  printer), 
perhaps  to  serve  later  as  an  input  to  a  frosting  operation. 


PILES  :  Files  are  the  basic  unit  of  permanent  data 

storage  on  the  HP.  'Hiey  hold  both  data  and 
processors.  There  are  many  different  types  of 
files,  just  as  there  are  many  different  purposes 
for  them.  However,  as  an  ALIAS  user,  you  are 
likely  to  be  concerned  with  only  two  types:  text 
or  "editor”  files,  and  RELATE  files  (data  base 
storage  structures) . 

Files  that  belong  to  you  will  typically  be  kept  in 
your  personal  file  group.  The  HP  computer  lumps 
files  into  groups  for  organizational  purposes. 
There  are  a  large  number  of  ALIAS  groups,  but  you 
will  only  need  to  know  about  those  that  hold  oaca 
base  relations  (files)  and  about  your  own  personal 
group.  Your  personcd  group  will  be  named  after 
your  user  name  "base”.  For  example,  if  you  have 
user  names  JOHNA  and  JOHNR,  then  your  personal 
group  will  be  called  JOHN. 

A  file  name  is  composed  of  its  name  and  its  group 
separated  by  a  ".".  For  example,  "MYDATA. MYGROUP" 
is  a  file  called  "mydata"  located  in  the  "mygroup" 
group.  When  you  want  to  refer  to  a  file  (say  in  a 
PURGE  command)  you  must  give  both  the  file  name 
and  group  name  unless  the  file  is  in  your  personal 
group,  in  which  case  you  need  give  only  the  file 
name  portion. 

2.4  YOUR  ENVIRONMENT 

As  you  use  ALIAS  you  may  find  it  helpful  to  think  of  your 

actions  as  movements  within  a  pi^sical  space,  e.g.  movements  in  a 
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house  with  many  rooms.  This  can  be  helpful  because  what  you  can 
do  will  depend  on  "where  you  are",  i.e,  on  your  context.  You 
can  only  wash  clothes  in  a  laundry  room;  you  can  only  change  data 
in  the  ALIAS  data  base  using  the  DBU.  If  you  ever  become  com¬ 
pletely  confused  about  what  is  happening,  the  most  likely  cause 
is  thinking  you  are  in  one  place  when  you  are  actually  in 
another. 

Such  confusion  can  occur  since  you  must  often  look  closely 
to  identify  your  context.  The  indicator  can  be  as  subtle  as  the 
character (s)  used  as  the  prompt  (i.e.  what  the  computer  prints 
to  tell  you  it  is  ready  for  your  next  command).  The  MPE  context 
is  identified  by  the  ":"  prompt,  for  example,  while  the  text 
editors  use  a  "/". 

Most  ALIAS  software  is  ■ena-ori'?!nted,  i.e.  it  presents  you 
with  a  full  display  screen  of  information/choices  at  a  time, 
making  the  context  somewhat  easier  to  identify.  The  nature  of 
the  information  on  the  display  and  especially  the  title  at  its 
top  are  good  indicators.  For  example,  you  can  always  tell  you 
are  "in"  the  ALIAS  Command  System  because  a  line  reading 
"*  ALIAS  COMMAND  SYSTEM  *"  will  appear  at  the  top  of  its  menus. 

The  sample  session  in  Section  3  will  illustrate  all  of 
ALIAS'  contexts. 

Closely  related  to  the  notion  of  context  is  that  of  your 
enviromeiit.  Where  context  is  the  room  you  are  in,  your  envi¬ 
ronment  is  the  scent  of  the  air  you  breathe,  the  kind  of  music 
playing  in  the  background,  etc.  You  can  change  these  things,  but 
once  set  they  will  remain  constant  no  matter  what  "room"  you  are 
in.  Examples  of  things  which  are  part  of  your  ALIAS  environment 
are  the  printer  your  reports  come  out  on  and  the  type  of  terminal 
ALIAS  thinks  you  are  using. 


Your  main  activity  as  an  ALIAS  user  will  be  giving 
conaands  in  response  to  the  various  prompts.  These  commands  are 
the  primary  instructions  (as  defined  in  Section  2.2}  that  ALIAS 
expects.  Commands  can  have  a  variety  of  effects,  from  displaying 
a  different  menu  to  deleting  some  data  from  the  data  base.  The 
main  thing  which  makes  different  contexts  different  is  that  the 
commands  which  you  can  give  (or  their  effects)  are  not  the  same. 

Commands  can  be  divided  into  three  basic  groups:  choices, 
instructions,  and  settings.  A  choice  command  is  one  which 
indicates  what  it  is  you  want  to  do  next,  or  which  is  an  answer 
to  an  explicit  question.  Choice  commands  often  change  your 
context. 

A  setting  command  is  one  which  you  use  to  change  a  system 
value,  e.g.  which  printer  your  output  will  appear  on.  The  way 
you  change  a  setting  is  by  telling  ALIAS  which  value  you  want  to 
change  and  what  you  want  to  change  it  to.  For  example,  you  might 
set  value  3,  "your"  printer,  by  "3=DAISY". 

An  instruction  is  a  command  which  tells  the  part  of  the 
system  you  are  working  with  to  take  some  action:  delete  some 
data,  find  some  data,  etc.  Instructions  and  choices  are  similar; 
they  differ  in  that  instructions  implement  a  change  somewhere,  or 
specify  how  something  is  to  be  done. 

There  are  defaults  for  many  things  in  ALIAS.  Defaults  are 
variable  vcdues  or  instructions  which  are  used  UhlggS.  Y0W_5Pgcify 
otheyw ig^ . 

Most  ALIAS  environments  are  based  on  menus,  screens,  or 
pages.  The  three  are  similar  in  that  each  takes  up  the  whole 
display  on  your  terminal.  When  ALIAS  shows  a  menu,  screen,  or 
page  to  you  the  first  thing  it  does  is  blank  the  display;  then  it 
types  out  the  menu/screen/page. 


The  three  differ  in  the  kind  of  information  shown  and  in 
the  method  they  expect  you  to  use  to  give  commands  and  set 
values.  Menus  and  screens  can  both  present  lists  of  choices  for 
your  next  action,  or  can  show  values  you  can  change.  But  in 
menus  you  are  expected  to  make  your  choices  and  settings  in  the 
usual  line-oriented  fashion,  while  screens  are  "f ill-in-the- 
blank”  oriented. 

This  terminology  may  be  a  little  confusing,  since  "menu” 
usually  refers  to  a  list  of  choices  for  your  next  move,  inde¬ 
pendent  of  the  method  you  use  to  specify  which  choice  you  want. 
Although  the  distinction  made  here  is  important,  it  will  always 
be  obvious  to  you  from  the  contents  of  the  display  what  you  face: 
if  you  see  the  word  "COMMAND"  near  the  top  of  the  display  next  to 
a  bright  green  or  white  "blank  space"  in  inverse  video,  then  you 
are  in  a  screen.  If  the  last  thing  typed  as  the  display  is 
filled  is  the  prompt  "COMMAND:"  then  you  are  in  a  menu.  Either 
could  be  presenting  you  with  a  list  of  choices  to  pick  from  or  a 
set  of  values  for  your  inspection  and  modification. 

A  page  requires  line-oriented  responses  from  you  (it  will 
prompt  you  for  commands  instead  of  presenting  a  f ill-in-the-blank 
area  in  inverse  video) .  This  makes  it  similar  to  a  menu,  but 
pages  present  more  complicated  data  such  as  lists  or  tables. 

Often  they  are  so  large  that  they  cannot  fit  on  your  terminal's 
display,  so  you  are  given  the  capability  to  "turn"  the  page,  i.e. 
to  look  up  or  down  and/or  right  or  left.  Paging  is  the  act  of 
changing  which  segment  of  the  list/table  you  are  looking  at. 

Let's  continue  with  the  notion  that  use  of  ALIAS  is  like 
moving  among  the  rooms  of  a  building.  Each  menu,  screen,  or  page 
is  like  a  room,  any  of  which  you  are  free  to  enter  (if  security 
permits).  However,  there  are  limits  on  how  you  can  move  from  one 
room  to  another  in  some  cases.  In  particular,  menus  are  always 
organized  in  a  hierarchy.  Figure  2-1  pictures  a  hierarchy, 
which  is  like  an  upside-down  tree. 
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In  moving  eunong  menus  in  a  hierarchy,  you  must  always  stay 
on  the  paths  or  branches.  Thus  if  you  start  in  the  top  menu  and 
work  down  three  levels  of  a  branch,  you  will  have  to  work  back  up 
that  branch  before  you  can  use  the  menus  on  another  branch  (there 
are  shortcut  commands  that  make  this  easier) . 

Screens  are  organized  in  hierarchies  too,  but  it  is  often 
possible  to  "jump"  across  branches  where  they  are  involved. 

Think  of  the  ALIAS  Core  as  a  convention  center  designed  to 
handle  several  related  conferences  at  once.  The  only  way  in  is 
via  a  central  foyer,  which  opens  on  several  suites  devoted  to 
particular  conferences.  These  suites  may  or  may  not  have  hierar¬ 
chical  room  organization - you  may  or  may  not  be  able  to  walk 

freely  from  any  room  to  any  other  without  backtracking.  However, 
to  step  from  one  conference  to  another,  you  mus^  90  back  through 
the  foyer,  the  top  of  a  grand  hierarchy. 

2.5  DATA  BASE  CONCEPTS 

The  ALIAS  data  base  is  organized  along  relational  lines 
(rather  than  network  or  hierarchical  lines).  It  is  composed  of 
relations,  which  are  just  independent  tables  with  rows  and 
columns  of  data.  These  relations/ tables  are  stored  in  the  form 
of  HP  files,  accessible  by  use  of  the  RELATE  DBMS. 

Figure  2-2  shows  a  sample  relation.  This  one  has  three 
rows  of  five  columns  each  with  some  construction  schedule  infor¬ 
mation.  Notice  that  each  row  is  dedicated  to  a  particular  ship, 
and  that  each  column  is  for  a  single  piece  of  information  about 
the  ships. 

Relations  typically  can  have  an  unlimited  number  of  rows 
(i.e.  can  handle  as  many  ships  as  you  want),  but  only  the  spe¬ 
cific  columns  they  were  created  with.  Thus  if  the  owner  of  the 
sample  wanted  to  start  tracking  launch  dates,  he  would  have  to 
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create  a  new  relation  with  six  columns  instead  of  five  and  then 
move  his  existing  data  from  the  sample  relation  into  the  new  one. 

Columns  in  relations  are  usually  called  fieldSr  each  of 
which  has  a  field  name.  You  can  use  the  field  names  as  part  of 
your  RELATE  commands  to  manipulate  data.  Rows  are  called  tuples 
or  records. 

Relations  always  have  key  fields.  Key  fields  are  the  ones 
whose  values  you  give  when  you  ask  that  specific  data  be 
extracted  from  a  relation  and  shown  to  you.  In  the  sample»  the 
primary  key  fields  are  CLASS  and  HULL.  The  sample  relation 
holds  information  about  individueU.  ships,  and  the  contents  of 
these  two  fields  (columns)  identify  which  ships  ai^  given  record 
(row)  is  for.  In  this  manual,  the  term  key  will  always  refer  to 
the  primary  key  fields. 

There  can  be  other  keys  as  well.  In  fact,  ar^  field  or 
ccxnbination  of  fields  can  form  the  k^  of  a  query.  For  example, 
we  might  ask  RELATE  to  tell  us  which  ships  recorded  in  the  sample 
relation  were  awarded  before  the  year  2000  but  delivered  after 
2000  (we  would  be  told  FPG-7:99  and  DDG*‘51:81);  in  this  case,  the 
key  is  AWARD, DELIVERY. 

The  key  or  primary  key  fields  are  those  whose  values  can 
be  used  to  uniquely  Identify  a  record.  If  you  are  an  experienced 
RELATE  user  you  know  that  RELATE* s  inner  workings  are  such  that  a 
relation  need  not  have  a  key  in  this  sense,  i.e.  it  may  contain 
duplicate  data.  However,  ALIAS  data  base  relations  are  created 
and  managed  by  the  Data  Base  Updating  System  in  ways  that  ensure 
there  is  always  a  primary  or  unique  key. 

RELATE  offers  a  service  closely  related  to  keys  called 
indexing.  Indexes  are  alternative  sort-orderings  which  can  be 
used  for  printout  of  the  contents  of  a  relation.  The  default 
sort-ordering  is  just  the  order  in  which  the  data  was  entered. 
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which  is  usually  not  very  useful.  For  example,  we  might  want  to 
print  out  the  data  in  the  sample  relation  in  Figure  2-2  by  ship 
on  some  occasions  (i.e.  by  class, hull),  but  by  date  of  award  on 
other  occasions. 

Indexes  can  be  either  permanent  or  temporary.  A  permanent 
index  makes  an  ordering  instantly  available,  but  imposes  some 
overhead  on  data  base  updating  operations.  On  the  other  hand,  it 
may  take  RELATE  several  minutes  to  set  up  a  temporary  index. 

In  thinking  about  how  to  use  the  ALIAS  data  base  it  is 
important  to  remember  that  the  various  files/relations  are  in 
fact  related  to  one  another  even  though  they  are  technically 
completely  separate.  In  particular,  they  can  be  merged  or 
joined  using  the  values  of  similar  fields  in  separate  relations. 
For  example,  say  that  in  addition  to  the  sample  relation  in 
Figure  2—2  there  was  a  second  one  with  the  fields  CLASS  and  TONS. 
Using  RELATE' s  SELECT  command,  it  would  be  possible  to  print  out 
a  list  of  ships  in  the  sample,  their  dates,  and  their  displace¬ 
ments.  In  fact,  much  more  complex  and  powerful  things  can  be 
done,  making  it  possible  to  answer  complicated  questions  by 
combining  the  information  in  severed  data  base  files. 

See  the  RELATE  manueds  for  more  infonnation  about  use  of 
RELATE. 

2.6  SCENARIOS 

One  of  the  most  useful  features  of  ALIAS  and  the  ALIAS  data 
base  is  its  capability  to  handle  multiple  studies  simultaneously. 
Tt^o  people  can  be  using  the  ^stem  at  the  same  time,  one  working 
on  a  standard  POM  projection  and  another  on  a  mobilization  exer¬ 
cise,  and  they  will  not  interfere  with  one  another.  They  will 
both  be  drawing  data  from  the  same  data  relations,  but  it  will  be 
different  data;  it  will  often  seem  to  each  that  he  has  a 
dedicated  data  base. 
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Exercises  or  studies  are  called  scenarios  in  ALIAS.  A 
scenario  is  really  a  named  container  for  a  study's  data,  and  is 
thus  very  much  like  a  file  drawer.  The  ALIAS  data  base  can  be 
thought  of  as  an  expandable  file  cabinet  which  gets  a  new  drawer 
any  time  someone  creates  a  new  scenario. 

When  you  use  the  Core  you  may  only  work  with  one  scenario 
at  a  time,  and  you  must  be  the  only  person  using  it.  This  keeps 
users  from  interfering  with  one  another.  In  terms  of  the  file 
drawer  analogy,  if  you  have  the  contents  of  the  drawer  on  your 
desk  and  are  making  some  changes,  Joe  at  the  next  de£;  should  not 
be  making  different  changes  at  the  same  time.  If  Joe  is  working 
out  of  another  drawer,  though,  then  there  is  no  problem. 

A  subtle  problem  with  this  arrangement  has  to  do  with  data 
base  updating,  the  process  of  keeping  the  data  base  current. 

Must  the  updating  be  done  for  each  and  every  scenario? 

Say  there  are  three  different  POM  projection  scenarios,  all 
of  which  need  to  make  use  of  the  latest  data  about  current  ship*’ 
yard  loads.  The  person  entering  the  latest  reports  from  the 
shipyards  doesn't  make  the  entries  three  times.  Instead,  regular 
data  updating  is  done  for  only  one  scenario,  called  "MAIN". 

Instead  of  having  their  own  current  yard  load  data,  the  POM 
projection  scenarios  make  use  of  the  current  load  data  from  MAIM. 
This  is  called  indirect  access,  as  opposed  to  direct  access  in 
which  each  POM  scenario  would  have  its  own  current  load  data 
(which  the  POM  scenario's  owners  would  have  to  keep  up-to-date 
themselves) . 

Instead  of  having  file  drawers  with  a  complete  set  of 
folders,  one  per  subject,  the  POM  scenarios  have  only  a  partial 
set  of  folders;  they  "borrow"  the  current  load  folder  from  the 
MAIM  drawer  whenever  they  need  current  yard  load  data.  This  way 


they  can  benefit  from  the  ongoing  data  updating  activity  which 
supports  MAIN. 


Howeveir  in  exchange  for  this  "borrowing”  privilege,  the 
POH  scenario's  creators  had  to  agree  not  to  make  any  changes  to 
main's  current  yard  load  data.  If  one  needs  to  change  this  data 
for  some  reason,  then  he  must  go  to  the  copier  and  make  up  his 
own  current  yard  load  folder  by  copying  MAIN's.  This  folder  goes 
in  his  drawer  and  he  loses  his  borrowing  privilege  (at  least 
until  he  throws  the  new  folder  away)  . 

The  creator  of  an  ALIAS  scenario  must  decide  at  creation 
time  which  subjects  he  will  borrow  (use  indirectly)  from  other 
existing  scenarios,  and  which  he  will  need  to  make  changes  to 
(use  directly  and  maintain  current  himself)  .  As  indicated  in 
the  analogy,  he  can  change  his  mind  later  about  these  structural 
decisions. 


2.7  MISCELLANEOUS  CONCEPTS 

FORMAT  CONTROL  A  format  control  file  is  a  device  which 

FILE:  you  use  to  specify  the  contents  and  format  of  a 

report  you  want  ALIAS  to  produce.  Format  control 
files  are  currently  required  by  the  Force  Level 
and  Battle  Group  report  generators.  You  make  them 
up  according  to  the  rules  given  in  Section  9  using 
one  of  the  text  editors. 

TEXT  EDITOR:  This  is  a  program  which  permits  you  to  create  and 

change  files  of  text.  The  editors  on  the  HP  are 
line-oriented  editors,  meaning  that  they  only  let 
you  work  with  one  line  of  text  at  a  time.  T^e 
best  editor  on  the  HP  is  called  "TDP”  (stands  for 
"Text-Document  Processor").  You  can  run  TDP 
either  from  MFE  or  from  within  ALIAS.  The  best 
introduction  to  HP  editors  is  the  introductory 
manual  for  the  one  called  EDITOR. 

PRIVELEGES:  ALIAS  is  a  secured  system,  meaning  that  ALIAS 

system  administrators  can  limit  the  things  that 
you  can  do.  The  list  of  things  that  you  are 
allowed  to  do  is  referred  to  as  your  priveleges. 

It  is  important  to  realize  that  your  actions  can 
affect  your  priveleges  to  some  extent.  For 
example,  if  you  create  a  scenario  which  uses  some 
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data  indicectlyr  you  will  not  have  data  change 
pciveleges  for  that  data  in  the  Data  Base  Updating 
system.  Also  realize  that  priveleges  depend  upon 
context:  if  you  are  running  RELATE  under  your  "R" 

user  ncune  you  will  not  be  allowed  to  change  data 
base  data,  but  if  you  are  in  the  DBU  you  probably 
will  be. 

OH-LINB  HELP:  Most  ALIAS  software  provides  at  least  some 

on-line  help.  If  you  are  uncertain  of  what  you 
are  supposed  to  do  at  any  point,  just  give  the  ”?" 
character  as  a  command.  You  are  likely  to  be 
presented  with  a  menu  offering  a  choice  of  many 
sorts  of  help  (general  description  of  what  you 
should  do,  list  of  available  commands,  etc.);  pick 
one  or  more  kinds. 

PARAHBTER:  Technical  term  for  a  variable  or  value  which 

appears  on  a  Command  ^stem  parameter  menu. 
Parameter  settings  typically  influence  how  a  given 
module  operates.  For  example,  setting  a  TIME 
UNITS  parameter  to  "FISCYR"  would  be  likely  to 
produce  different  results  than  setting  it  to 
'MONTHS". 

GATE:  A  particular  kind  of  parameter,  one  which  takes 

on  the  values  of  "ALL"  or  "LIST".  By  setting  the 
value  to  "LIST"  (even  if  that  already  appears  to 
be  its  value)  you  will  be  presented  with  a  page  or 
list  of  items  which  you  may  turn  on  or  off.  See 
Section  4  for  more  information. 

2.8  SUMMARY 

A  number  of  fairly  abstract  concepts  have  been  presented  in 
this  Section.  The  most  important  ones  to  know  before  going  on 
are: 

1)  CONTEXT:  ALIAS  is  like  a  building  with  many  rooms.  You 
can  do  different  things  in  different  rooms.  When  you 
are  finished  with  one  task  and  want  to  perform  another, 
you  must  "move"  to  a  different  context.  There  are  about 
naif  a  dozen  different  context  types  in  ALIAS.  By 
learning  to  recognize  the  types  and  the  manner  in  which 
things  are  done  in  each  one  you  will  find  yourself  able 
to  use  ALIAS  more  effectively. 

2)  INSTRUCTIONS  vs.  PROCESSORS  vs.  DATA:  Using  ALIAS  is 
the  process  of  giving  instructions  to  processors  which 
will  manipulate  data.  The  data,  however,  is  the  most 
important  part  of  the  system.  It  is  the  heart  of  any 
study.  Alwtys  remember  that  you  have  control  of  the 
data  values  through  the  Data  Base  Updating  system  and 


the  scenario  system- — you  can  change  anything.  The  data 
forms  a  picture  of  the  world:  if  you  want  to  do  an 
exercise  in  which  a  different  world  is  envisioned  (say 
more  shipyards)  you  need  only  change  the  picture. 

3)  SCENARIOS:  The  ALIAS  data  base  is  divided  into 
partitions  which  are  like  file  drawers.  Whenever  you 
use  ALIASr  you  can  only  use  one  scenario  at  a  time 
(though  you  may  be  able  to  "borrow”  some  data  from  other 
drawers").  This  ensures  that  you  do  not  interfere  with 

anyone  else's  work,  and  that  they  do  not  interfere  with 
yours.  However,  you  have  some  freedom  to  move  data  from 
one  scenario  to  another,  and  you  can  always  change  which 
scenario  you  are  working  with. 

4)  DATA  BASE:  The  ALIAS  data  base  is  a  set  of  separate 
tables  or  files,  each  holding  data  about  one 
well-defined  subject.  You  can  use  the  facilities  of  the 
RELATE  Data  Base  Management  System  to  sort,  combine, 
extract,  and  summarize  data  from  the  table  in  ways  that 
let  you  answer  many  different  types  of  questions. 
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This  Section  will  guide  you  through  a  sample  ALIAS  session 
in  which  a  number  o£  the  system's  features  will  be  demonstrated. 
Right-hand  pages  will  show  the  session  as  it  develops,  while  left 
hand  pages  will  offer  a  running  commentary  on  what  is  happening 
and  why.  A  typical  right  hand  page  will  show  two  screen 
"frames",  separated  by  a  line  of  "/////////"  characters.  The 
things  typed  by  the  user  will  be  in  bold  face,  while  those 
printed  by  the  computer  will  be  in  normal  type. 

The  goal  of  the  Section  is  to  introduce  you  to  the  oper¬ 
ation  of  ALIAS  software  by  examples,  not  to  thoroughly  explain 
each  feature  and  its  options.  Do  not  worry  if  there  are  steps 
whose  rationale  is  unclear.  If  you  come  away  with  a  general  idea 
of  how  ALIAS  works  you  will  be  prepared  for  the  in-depth  explan¬ 
ations  of  later  sections. 

The  data  you  will  see  in  the  sample  session  is  all  notional 
data,  not  an  accurate  representation  of  the  data  NAVSEA  uses. 
Also,  the  decisions  made  by  the  person  running  the  session  are 
not  those  of  a  seasoned  NAVSEA  analyst;  if  some  of  the  decisions 
seem  unrealistic  to  you,  you  are  probably  right  1 

The  session  does  attempt  to  present  in  a  reedistic  fashion 
how  one  might  go  about  performing  an  acquisition  program  planning 
task  with  ALIAS,  though.  The  task  conducted  in  the  session  is 
design  of  a  fiscal  1986  (Program  Objective  Memorandum)  POM  to 
support  deployment  of  17  carrier  battle  groups  by  the  mid-1990s, 
and  generation  of  a  rough  cost  estimate  for  this  POM. 

If  you  have  ALIAS  user  names  and  access  to  a  terminal  you 
can  run  the  session  as  you  read  it.  Be  aware  that  you  will 
probably  not  be  able  to  duplicate  it  exactly,  though,  because  the 
contents  of  the  data  base  will  have  changed  since  this  was 

written.  You  should  still  be  able  to  carry  out  most  functions 
even  if  your  results  are  somewhat  different. 

As  the  sample  session  develops  you  may  begin  to  feel  that 
ALIAS  offers  a  truly  bewildering  array  of  options  at  each  step. 

It  is  true  that  there  are  usually  many  different  things  you  can 
do  at  any  given  point.  This  is  the  case  because  ALIAS  tries  to 
serve  a  large  and  diverse  community  of  users,  who  require  a  large 
and  diverse  array  of  options.  It  is  not  necessary  that  you 
understand  all  the  options  in  order  to  use  the  system,  though. 

In  many  cases  you  can  get  along  just  fine  without  even  knowing 
that  many  of  them  exist.  The  best  way  to  learn  how  to  use  ALIAS 
is  to  concentrate  on  the  options  and  capabilities  which  seem  most 
relevant  to  your  needs.  In  this  way  you  will  begin  to  get  the 
feel  of  the  system,  which  is  the  most  important  thing. 


The  facing  page  shows  the  ALIAS  system  map,  which  pictures 
all  the  menus  currently  offered  by  the  Command  System.  It  is  a 
picture  of  the  top-level  options  available. 

When  operating  the  system  it  is  often  helpful  to  think  of 
your  actions  in  terms  of  moving  from  one  location  to  another  on 
the  map,  or  within  one  of  the  blocks  on  the  map.  This  makes  it 
easier  and  more  natural  to  constantly  keep  track  of  your  context 
(defined  in  Section  2),  just  as  you  keep  track  of  where  you  are 
in  the  back  of  your  mind  when  someone  else  is  driving.  Since 
your  options  depend  on  where  you  are  in  ALIAS,  you  can  avoid  much 
frustration  by  keeping  track.  If  you  become  lost,  you  can  turn 
back  to  the  map  and  attempt  to  locate  yourself.  The  map  is 
available  on-screen  from  any  Command  System  menu  by  giving  the 
command 


To  use  ALIAS  you  must  log  on  to  the  SEA  90  account  of  the 
NAVSEA  PMS  3  92  Hewlett-Packard  3000  computer.  You  will  only  be 
able  to  do  this  if  you  have  been  given  user  names  and  passwords 
by  an  ALIAS  system  administrator. 

To  log  on,  sit  down  at  a  terminal  connected  to  the  HP  and 
press  the  RETURN  key.  Whenever  you  want  to  get  HP's  attention, 
or  send  a  command  off  for  processing,  the  RETURN  key  is  the  first 
one  to  try. 

HP  will  respond  with  a  as  a  prompt.  You  should  have 
two  user  names,  one  ending  with  an  "A”  and  one  ending  with  an 
"R".  The  "A"  name  is  for  running  the  ALIAS  System  Core  and  its 
attached  modules;  the  "R"  name  is  for  running  the  RELATE  Data 
Base  Management  System  (DBMS)  .  Type  your  "A"  name  in  response  to 
the  colon.  In  the  printed  sample  session  the  user  is  named 
"JOHN".  He  has  user  neunes  "JOHNA"  and  "JOHNR". 

HP  will  ask  for  your  password.  It  will  not  appear  on  the 
screen  as  you  type  it  in/  for  security  reasons.  Type  it  blind 
and  hit  the  RETURN  key  (if  you  make  a  mistake,  you  have  up  to 
three  tries  to  get  it  right;  after  that  you  must  type  in  your 
user  name  again,  but  no  harm  is  done) . 

A  couple  of  bulletin-board  like  messages  will  appear,  and 
you  will  get  another  colon  prompt.  Type  "ALIAS".  The  ALIAS  Core 
system  will  start  up  and  will  print  a  welcome  message. 
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:HEU/)  J0BIIA.SEA90 

ENTER  USER  PASStfGRD: 

HP3000  /  NPE  W  C.B1.A2.  SAT,  OCT  20,  1984,  U:20  AM 
********************************************************** 
WEEKLY  BAOC  UP  OF  FILES  IS  NCW  TAKING  8-  2400  FEET  REELS 
OF  •miE  PND  LASTING  MORE  THAN  2  1/2  HOURS.  IT  IS  IMPERATIVE 
1HAT  USERS  OF  THE  SYSTEM  EURGE  OLD  FILES  ON  A  REGULAR  BASIS. 
************************************************************ 


Bulletin: 

****************************************************************** 
***********************************************************^****** 
*****************  IX)  NOT  r.FJg/R  your  TERMINAL  ********************* 
*****************  UNAHniNDED  ********************* 

*****************  SIGN  OFF  ill!  ********************* 
****************************************************************** 
****************************************************************** 


QID  OF  PROGRAM 

:ALIAS 


********************************** 
*  * 

*  WELOOME  TO  ALIAS  * 

*  VERSION  1.0  * 

********************************** 


>  SYSTEM  STARTVUP  IN  PROGRESS: 
-Loading  core  ^steni... 
-Connecting  to  data  base... 
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As  explained  in  Section  2,  ALIAS  presents  menus  and 
screens.  Both  offer  choices  and  accept  commands,  but  screens  are 
primarily  f ill-in-the-blank  oriented  while  menus  are  tell-it- 
what-to-do-with-a-command  oriented.  The  quickest  way  to  tell  one 

from  the  other  is  by  the  presence  of  inverse  video - if  there  are 

bright  white  or  green  rectangles  on  the  terminal,  you're  looking 
at  a  screen;  if  not,  it's  a  menu. 

The  first  thing  you  see  whenever  you  run  the  ALIAS  Core  is 
a  menu  put  up  by  the  scenario  system.  The  scenario  system  lets 
you  choose  what  scenario  (exercise/study)  you  want  to  work  with. 
You  must  always  have  a  "current  scenario".  Otherwise  ALIAS  will 
not  know  which  data  to  retrieve  from  the  data  base  to  support 
your  work. 

Most  ALIAS  screens  and  menus  print  a  few  of  the  commands 
they  will  accept  at  the  top  of  the  display  as  a  reminder.  By 
looking  at  this  help  (top  fraune,  facing  page),  JOHN  sees  he  is 
supposed  to  give  the  name  of  the  scenario  he  will  work  with 
initially.  Alternatively,  he  can  give  one  of  the  listed  command 
characters.  He  chooses  "*  to  find  out  what  scenarios  are 
available. 

The  response  appears  in  the  lower  freune.  Only  two  scen¬ 
arios  are  currently  available,  and  neither  looks  like  a  good  one 
for  an  experimental  session.  JOHN  concludes  he  had  better  make 
up  a  new  scenario,  which  he  is  allowed  to  do  at  this  point  by 
giving  the  "+"  command.  By  doing  this  JOHN  is  making  sure  that 
he  does  not  interfere  with  anyone  else's  work  by  accidentally 
changing  their  data. 

If  you  are  following  along,  you  can  skip  this  step  if  there 
is  a  scenario  available  which  you  can  use  without  destroying 
anyone's  work. 


3-6 


Current  scenario  is 


Scenario  choice  options  include: 

?  provides  help 

@  lists  existing  scenarios 

Shame  lists  the  ocmposition 
of  the  'n^nle'  scenario 
name  makes  the  'name'  scenario 
your  current  scenario 


exits  scenario  choice  system 
+  moves  you  into  scenario 

creation  menu 

&  re-dispieys  this  menu 


SCENARIO  CSOICE  MENU 
Name  of  scenario  to  use,  dr  Cannand  diaracter:  9 


///////////////////////////////////////////////////////////////////////// 


CURRENT  ;^IAS  SCENARIOS 

SCENARIO  O^TQR  LAST  USED  CSEAIED  READABLE  BY  CBAN5ABLE  BY 


mrr  EBA  10/18/1984  V17/1984  PCBLIC  PtBLIC 

QOFY  OF  IHE  MON  SCZNARIO;  TO  BE  USED  EOR  FIXING  UP  THE  DATA 
FROM  CSD6  SO  IHAT  SCQIARIO  MAIM  IS  A/AILABLE  AS  A  BACKUP. 
MAIN  CBA  10/W1984  9/21/1983  PUBLIC  IBA 

IHIS  SCENARIO  HCLD6  IHE  MAIN  DATA  FOR  1BE  ALIAS  SYSTEM 
rr  IS  1HE  CNLY  SCENARIO  WHICH  IS  MAINTAINED  BY  SYSIEM  DATA  EK 

Hit  <REroiN>  for  return  to  conmand  menu: 


Nane  of  scenario  to  use,  or  Conmand  character:  * 


Scenario  creation  is  a  multi-stage  process.  In  the  first 
stage#  JOHN  is  prompted  for  some  basic  information  about  the 
scenario  he  wants  to  create:  its  name,  whether  other  people  will 
be  allowed  to  use  it  and/or  change  its  contents#  and  a  descrip¬ 
tion.  The  description  can  be  several  lines  long. 

Notice  that  JOHN  could  have  given  one  of  the  command  char¬ 
acters  instead  of  the  new  scenario's  name.  In  particular,  if  he 
had  typed  the  "+"  by  accident  in  the  previous  menu#  he  could 
"back  out"  by  giving  the  command  at  this  point.  The 
("pop")  command's  effect  is  always  to  take  you  back  to  where  you 
were  before.  When  given  in  a  Command  System  menu  such  as  those 
listed  on  the  system  map  shown  a  few  pages  ago#  its  effect  will 
always  be  to  pop  you  to  a  higher  level  on  the  map. 
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Current  scenario  is 


Soeneurio  creaticxi  options  include: 

?  provides  help  I  exits  scenario  choice  system 

@  lists  existing  scenarios  I  6  re-displays  this  mmu 

name  specifies  the  name  of  your  I  diame  lists  the  composition 

new  scenario  i  of  the  'name'  scenario 


SCENARIO  CREIKTICXJ— STAGE  1 

NAME  of  new  scenario,  or  Q0M1AND:  demo 

Do  you  wish  to  allow  all  ALIAS  users  to 
examine  the  contents  of  this  scenario?  y 

Do  you  wish  to  allow  all  ALIAS  users  to 
modify  the  contents  of  this  scenario?  y 

Please  give  a  description  of  this  scenario*  Terminate  it  with  a  '//'  line. 


In  stage  two  of  scenario  creation  JOHN  must  specify  the 
makeup  or  contents  of  his  new  scenario.  A  scenario  can  be 
thought  of  as  a  personal  copy  of  the  data  in  the  data  base.  The 
copy  can  start  as  a  clean  slate/  or  as  an  actual  copy  of  the  data 
belonging  to  an  existing  scenario. 

The  data  base  is  divided  into  groups  or  families  along 
functional  lines.  Scenario  makeup  is  specified  by  group,  making 
it  possible  to  take  data  from  several  existing  scenarios.  John, 
however,  elects  to  have  the  new  scenario  (named  "demo")  start  out 
as  a  copy  of  the  "f.ixit"  scenario.  He  responds  "fixit"  after  the 
query  for  each  data  base  group.  (If  he  had  wanted  to  start  with 
a  clean  slate  for  any  group,  he  would  have  responded  "demo"  to 
the  appropriate  "COMMAND  or  NAME:"  prompt.) 

The  group  names  are  short  and  rather  mysterious.  Here  is 
what  they  stand  for: 

1)  CURRJ:  Current  shipyard  jobs,  both  new 
construction/conversion  and  repair.  In  Version  1.0  of 
ALIAS,  the  data  involved  is  primarily  schedules. 
"Current"  jobs  are  those  awarded  but  not  yet  delivered. 

2)  DESCJ :  Job  Descriptions.  A  job  description  tells  how 
much  time  and/or  resources  it  takes  to  do  a  shipyard  job 
of  a  given  type  on  a  ship  of  a  given  class. 

3)  HISTJ :  Historical  shipyard  jobs.  Similar  to  the  CURRJ 
group,  but  for  jobs  which  have  been  completed. 

4)  MISCJ :  Miscellaneous  job-oriented  information.  Primary 
ship-class  descriptions  and  individual  ship  retirement 
dates. 

5)  PARAMS;  The  name  stands  for  "parameters",  which  in  turn 
refers  to  the  values  which  appear  on  some  Command  ^stem 
menus.  Parauneters  control  the  operation  of  many  ALIAS 
modules.  They  are  always  "owned”  by  a  particular 
scenario,  so  a  group  is  required  for  their  storage  (note 
that  the  HP  file  group  used  is  called  "MNUREL",  not 
"PARAMS") . 

6)  PROJJ :  Projected  jobs.  Like  CURRJ  and  HISTJ,  but 
shipyard  jobs  which  have  not  yet  been  awarded. 

7)  YARDS:  Information  about  shipyards. 

Notice  that  JOHN  is  also  asked  if  he  will  want  to  make 
changes  to  the  data  in  each  group.  If  he  says  yes,  an  actual 
copy  of  the  source  data  he  requests  will  be  made  for  his  use.  If 
he  says  no,  he  will  be  using  the  data  from  the  source  scenario 
(fixit)  "indirectly".  More  on  this  later. 


Scenario  creatim  opti<»is  include: 

?  provides  h^p 

§  lists  existing  scenarios 

name  specifies  the  name  of  the 
scenario  to  take  data  from 
for  a  particular  EB  fanily. 


Current  scenario  is 

exits  scenario  choice  ^stem 
&  re-displeys  this  menu 
diame  lists  the  composition 
of  the  'name*  scenario 


SCENARIO  a?EA!riCN — STAGE  2 

Hease  give  the  name  of  the  sceneurio  to  take  data  for  group  C2JRR7  from. 
OOMAND  or  NAME:  f  izit 

Will  you  want  to  make  cuy  changes  to  the  data  in  this  group?  n 

Slease  give  the  nane  of  the  scenario  to  take  data  for  group  DESGJ  from. 
QOMAND  or  NAME:  fizit 

Will  you  want  to  make  aiy  changes  to  the  data  in  this  group?  y 

Hease  give  the  nane  of  the  scenario  to  take  data  for  group  HISTJ  from. 
OOMAND  or  NAME:  f  izit 

Will  you  want  to  make  aiy  changes  to  the  data  in  this  group?  n 

Hease  give  the  nane  of  the  scenario  to  take  data  for  group  MISGJ  from. 
OOMAND  or  NAME:  fizit 

Will  you  want  to  make  ary  changes  to  the  data  in  this  group?  n 

Hease  give  the  nane  of  the  scenario  to  take  data  for  groi^  PARAMS  from. 
OOIfAND  or  NAME:  fizit 

Hease  give  the  name  of  the  scenario  to  take  data  for  group  FRQ7J  fron. 
ODIfAND  or  NAME:  fizit 

Will  you  want  to  make  cuy  changes  to  the  data  in  this  group?  y 

Hease  give  the  nane  of  the  scenario  to  take  data  for  groip  YARDS  from. 
OOMAND  or  NAME:  fizit 

Will  you  want  to  make  euy  changes  to  the  data  in  this  group?  n 


After  the  questions  have  been  answered  for  all  the  groups, 
ALIAS  displays  a  series  of  messages.  The  first  is  the  infamous 
■coffee  cup",  recommending  that  JOHN  take  a  break.  The  coffee 
cup  is  a  wry  warning  that  things  are  about  to  get  very  slow. 

Some  parts  of  ALIAS  can  take  a  long  time  to  execute,  particularly 
during  peak  daytime  computer  usage  hours  when  everything  is  slow 
anyway.  Scenario  creation  is  one  of  these  tasks;  it  can  be 
counted  on  to  take  at  least  five  minutes  during  the  day  and  often 
much  more. 

The  "Copying"  messages  report  on  progress  of  the  creation. 
Note  that  the  qroup  name  of  each  relation  (the  part  in  capitals 
after  the  "."  in  each  message)  corresponds  to  a  group  neune  on  the 
previous  page  (except  for  ".MNUREL",  which  is  where  the  "PARAMS" 
are  stored) .  The  only  group  names  which  appear  are  those  for 
which  JOHN  responded  "yes"  when  asked  if  he  expected  to  change 
data  in  that  group. 

When  the  "LOADING  PARAMETERS"  message  comes  up  ALIAS  is 
almost  ready  for  use. 


Now,  while  I'm  doing 
some  processing, 
w^  don't  you  just 
sit  back,  relax,  and 
have  a  nice,  hot  exp 
of  Coffee.... 


Goiying  data  in  relation  NCJtAT.CESCI 
Copying  data  in  relation  NC7IXZ)M.DESCJ 
Copying  data  in  rdatjon  ASNI>RM.MKJBEL 
Oocying  data  in  relation  EN(^SN.MNaREL 
Copying  data  in  relation  ELBEFT.MtJREL 
Copying  data  in  relation  V^CZ<S.MI1JREL 
Copying  data  in  relation  VAL^.MUBEL 
Ooiying  data  in  relation  VXJTXP.MNOREL 
Copying  data  in  rd.ation  VLRJCB.MTOFEL 
Copying  data  in  relation  NGJ(XZ}M.FRa]J 
Copying  data  in  rdation  NCJGDAT.FRQTJ 
Copying  data  in  relation  RETCXAT.FRQJJ 
Copying  data  in  relation  RE70a3M.FRQ7J 


********************************** 
*  * 


*  LCADINS  PARAMEnXRS 

* 


* 

* 


********************************** 
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^  When  you  run  the  ALIAS  Core  you  always  start  out  in  the 
Command  System"  context.  A  reminder  of  this  fact  is  the  "*ALIAS 
COMMAND  SYSTEM*"  label  at  the  top  of  the  menu.  This  label 
appears  on  every  Command  System  menu. 

The  first  menu  to  be  presented  by  the  Command  System  is 
always  the  "TOP"  menu.  In  this  menu  six  choices  are  available, 
corresponding  to  six  broad  types  of  activity. 

Now  that  JOHN  has  created  the  scenario  he  will  be  working 
with  he  is  ready  to  start  designing  his  revised  POM.  He  is 
operating  on  the  assumption  that  the  scenario  he  took  his 
starting  data  from,  FIXIT,  was  one  containing  a  POM  supporting  a 
15-carrier  battle  group  Navy.  He  can  therefore  make  a  first 

fuess  at  the  new  POM  by  just  adding  enough  ship  construction  jobs 
o  it  to  fill  out  two  more  battle  groups. 

The  best  tool  for  fast,  high  level  design  of  an  overall  SCN 
POM  is  the  Manual  Assignment  Editor  ("assignor"  for  short).  The 
assignor  lets  you  create,  inspect,  and  modify  program  designs 
^ing  a  timetable  representation  of  the  program  schedules.  This 
is  much  faster  than  working  at  the  level  of  the  individual 
schedules  themselves.  JOHN  therefore  chooses  option  4. 

ALIAS'  response  is  to  present  another  menu,  this  one  with 
only  two  choices.  JOHN  can  either  look  at  the  assignor  initial- 
ization  parameters,  which  are  variables  whose  settings  control 
what  the  assignor  does,  or  he  can  go  ahead  and  run  the  assignor. 
Since  he  doesn't  know  what  parameter  settings  he  inherited  from 
the  "fixit”  scenario,  he  opts  to  look  them  over. 


>•] 


*  vj 


CAII.  NON-ALIAS  FRXESSORS 
DATA  BASE  UTOATINS  SYSTEM 
MANJi^  ASSIGNMENT  EDITCR 
EORCE  BEK3RT  GQlEXUaDR 

SCQIARIO  CBOICS/IAKEUP  SYSTEM 


GOEMAMD:  4 


///////////////////////////////////////////////////////////////////////// 


Menu  is  ASSIGN 


*  i«<IAS  OXIMAND  SYSTEM  *  Scenario  is 
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The  parameters  are  set  to  display  assignments  in  terms  of 
fiscal  year  of  ship  award  (1  and  7)  from  1980  through  2000  (2  and 
3).  Only  projected  jobs  will  be  displayed  (10).  When  the 
assigner  creates  new  schedules  based  on  JOHN'S  changes  to  the 
POM,  it  will  attempt  to  generate  them  such  that  the  start- 
construction  milestones  of  the  ships  in  each  program  at  each  yard 
will  be  spread  evenly  over  time  (8  and  9) .  On  the  assigner 
display  screen,  shipyards  will  be  displayed  in  the  order  they 
were  shown  during  the  last  assigner  run,  while  ship  classes  will 
be  alphabetized  within  yards  (11  and  12).  The  assigner  will 
re-type  its  displays  only  when  JOHN  tells  it  to,  not  automat¬ 
ically  after  each  command  (13).  Parameters  4,  5,  and  6  are 
"gates”  to  "list  menus”.  Their  pages  offer  lists  of  the  yards, 
ship  classes,  and  job  types  that  the  assigner  is  capable  of 
working  with.  By  marking  the  members  of  the  lists  as  "on"  or 
"off",  JOHN  can  indicate  which  yards/classes/ job  types  he  wants 
to  work  with  for  this  run.  A  setting  of  LIST  on  the  parameter 
menu  (as  opposed  to  ALL)  indicates  that  some  of  the  list  members 
may  be  turned  off. 

If  you  are  running  a  sample  session  as  you  read  this,  you 
can  look  at  one  of  the  menus  by  giving  the  command  "4=LIST". 

JOHN  doesn't  worry  about  the  list  statuses,  though.  He 
sets  the  time  period  of  interest  to  fiscal  1986-94  and  the  ship¬ 
yard  display  order  to  alphabetic,  and  leaves  the  menu. 

Back  in  the  assigner  choice  menu  again,  he  asks  that  the 
assigner  be  executed.  The  assigner  informs  him  of  its  progress 
as  it  reads  the  existing  construction  schedules  for  projected 
jobs  in  the  DEMO  scenario. 
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MANUAL  ASSIGNER  lOXJLE  INITIALIZATICM  PARAMETERS 

1.  TIME  UNIT 

»  FISCYR 

(FISCYR,  CALYR,  QIR,  MONTH,  WEEK,  DAY) 

2.  startug  date 

-  1/  V1980 

(MV1»/YYYY) 

3.  ENDING  DATE 

»  12/31/1999 

(M1/T3D/YYYY) 

4.  CANDIDA!1E  SHIP  YARDS 

=  LIST 

(ALI/tilST) 

5.  CANDIDATE  SHIP  CLASSES 

=  list 

(ALI/LIST) 

6.  C^IDATE  JCB  TYPES 

«  LIST 

(ALI/LIST) 

7.  DISPLAY  BASIS 

-  JWD 

(APEROP,  /WD,  START,  KEEL,  INCH,  DEL  IV) 

8.  ADJUST  BASIS 

=  START 

(APPBOP,  AfD,  START,  KEEL,  INCH,  DELIV) 

9.  ADJUST  MODE 

-  IROGRAM 

(NONE,  IROGRAM,  COMELX-GRCUP) 

10.  JCBS  EKXB  OPTION 

=  PROJ 

(ALL,  CURR/PRCJ,  PROJ) 

11.  SHIPCLASS  SORT  ORDER 

-  ALIHABEnC 

(ALIHABETIC,  INHJT  ORDER) 

12.  SIPYARD  SORT  ORDER 

-  INPUT  ORDER 

(ALIHiSETIC,  INIUT  ORDER) 

13.  AUTO  REFRESH 

s  GET 

(0N,(FF) 

OOIflAND:  2»10/1/1385 

COMMAND:  3-9/31/1394 

COMIAND:  12-ALPHA 

COmAND: 

Saving  parameter  settings... 

///////////////////////////////////////////////////////////////////////// 

Menu  is  ASSIGN  * 

ALIAS  COMMAND  SYSTEM  *  Scenario  is  DEMO 

MANJAL  ASSE31ER  SFEaFICftTICNS 

1.  ASSIGNER  INITIALIZAT^  PARAMEHRS 

2.  EXECUTE  1HE  ASSIGNEE 

OOmAND;  2 

Starting  up  Manual  Ship  Assigner.  Etoect  a  one  to  five  minute  del^ 
Loading  assignnents  for  yard  A/CNDALET 
Loading  assignm&its  for  yard  BIW 
Loading  assignnents  for  yard  ES  GFOT 
Loading  assignments  for  yeurd  GDQ 
Loading  assignnents  for  yard  IIGAIIiS 
Loading  assignments  for  yeu:d  MARINET 
Loading  assignnents  for  yard  NASSOO 
Loading  assignments  for  yard  NN0?S 
Loading  assignnents  for  yard  PE24NSBIP 
Loading  assignmeits  for  yeurd  PETERSCN 
Loading  assignnents  for  yard  PH  NSY 
Loading  assignments  for  yard  TACOMA 
Loading  assignnents  for  yard  TOED  SEA 
Loading  assignments  for  yard  UNKBU® 


Now  we  are  in  a  new  context r  the  assignments  editor  con¬ 
text.  Oriented  towards  data  display  and  modificationr  the 

assigner's  displays  are  pages  rather  than  menus  or  screens - 

notice  that  there  is  no  inverse  video,  if  you  are  running  a 
session,  and  no  list  of  choices.  As  in  the  parameter  menu  he 
just  worked  with,  JOHN  will  make  changes  by  using  editor-like 
commands  (Add,  Delete,  Modify,  etc.)  rather  than  by  filling  in  or 
changing  fields  on  the  display. 

There  is  a  lot  of  information  packed  onto  an  assignor 
display.  Rather  than  explain  it  all  at  once,  we  will  discuss  it 
a  bit  at  a  time  as  the  session  continues.  Notice  for  now  that 
the  top  line  tells  JOHN  that  he  is  in  a  new  context  ("*SHIP 
ASSIGNMENTS*"  rather  than  "*  ALIAS  COMMAND  SYSTEM  *"),  that  the 
period  numbers  forming  column  headers  represent  fiscal  years 
(FISCYR) ,  and  that  he  is  using  scenario  DEMO. 

The  body  of  the  assignor  table  is  marked  out  in  subsec¬ 
tions,  one  per  yard,  by  grid  lines.  Each  individual  ship  class 
that  a  yard  is  to  do  work  on  has  its  own  line  within  the  subsec¬ 
tion;  the  numbers  on  the  line  tell  how  many  awards  the  yard  will 
receive  each  fiscal  year  for  jobs  in  that  class  (they  are  awards 
because  that  was  the  display  basis  date  setting  in  the  assigner's 

par^eter  menu - they  could  just  as  easily  be  starts  or 

deliveries).  For  example,  AVONDALE  will  get  contracts  to  build 
two  LSD-41 's  in  fiscal  1986  and  one  in  fiscal  1987. 

Notice  that  each  yard  has  a  number,  which  follows  its  name, 
and  each  class  has  a  number  preceding  its  name.  These  numbers 
are  the  means  of  picking  out  a  line  of  the  display  to  make 
changes  to.  JOHN  wants  to  give  BATH  two  CG-47's  in  fiscal  '89 
instead  of  just  one;  to  do  this  he  asks  to  modify  the  assignments 
for  yard  2,  class  1  by  giving  the  "M  2.1"  command.  The  assigner 
responds  with  a  miniature  version  of  the  display  showing  the 
current  assignments  for  2.1,  the  bottom  line  of  which  is  a  row  of 
dots  which  act  as  a  typing  guide.  All  JOHN  has  to  do  is  space 
over  and  put  a  "2"  in  the  column  he  wants  to  alter.  BATH's  CG-47 
assignments  in  other  years  will  remain  unchanged. 

That  was  the  only  change  JOHN  wanted  to  make  to  the 
assignments  showing  on  this  page  of  the  assigner  display.  He 
tells  the  assigner  to  go  on  to  the  next  page  with  the  "+" 
command.  Since  he  had  left  AUTO  REFRESH  set  to  "off"  in  the 
parameters  menu,  the  assigner  doesn't  actually  type  out  page 
2---it  just  gets  ready  to.  JOHN  asks  it  to  show  the  new  page 
with  the  "fit"  command 
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(?=help)  >  + 
(?=h^p)  >  fc 
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Notice  that  the  page  number  at  the  top  right  now  reads  ''2A” 
rather  than  "lA”.  Although  it  will  not  be  used  in  this  session, 
the  assigner  can  page  right  and  left  as  well  as  up  and  down.  It 
can  work  with  an  effectively  unlimited  number  of  vertical  or 
up/down  pages,  and  with  up  to  13  horizontal  or  right/left  pages. 
The  13  pages  can  hold  up  to  20  columns  each,  giving  the  assigner 
a  260-period  capacity.  You  can  make  a  260-year  projection!  Or 
more  usefully,  you  can  look  at  a  five-year  program  in  terms  of 
months,  a  relatively  high  level  of  time-resolution. 

In  the  page  number  at  the  top  of  the  display,  the  number 
tells  what  vertical  page  JOHN  is  on,  while  the  letter  tells  what 
horizontal  page. 

Flip  back  to  the  previous  page  and  compare  the  TOTALS  line 
at  the  bottom  with  the  one  on  the  facing  page.  Notice  that  the 
”89”  column  is  now  greater  by  one  (31  rather  than  30,  since  an 
extra  CG-47  was  assianed),  and  the  grand  total  at  the  bottom 
right  is  also  (145).  These  totals  are  not  single-page  totals, 
but  are  for  all  pages. 

On  this  page  JOHN  makes  a  modification  to  CG-47  assignments 
at  INGALLS  in  a  fashion  similar  to  the  BATH  change.  He  then 
wants  to  add  assignments  to  the  NNENS  yard  for  a  class  NN^S  does 
not  yet  have.  He  asks  to  Add  to  yard  8  (”A  8”),  and  is  given  a 
prompt  similar  to  the  one  used  for  modify,  except  that  he  must 
fill  in  the  ship  class  name  as  well  as  the  assignments.  Then  he 
asks  for  the  next  page  using  the  ”+”  and  ”&”  commands. 
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Scenario:  DEMO 
Yard  Period:  |  1 


ASSlSNMOnS* 
5  6  7  8  9 


Paige  2A  Time  in:  FISGfR 


ShipcLass  T| 86  87  88  89  90  91  92  93  94 


IMG^S 

1  BD>61 

2  OS-47 

3  EDQ-51 

4  I£D 


1  MCM-1 

2  MSH-1 
NASSGO 

1  M>187 

2  fOE 

3  AR 

4  IfD-4 


U  FI 


2  SSN-688  12  2  2  1  2 

I 1 — H H — H — H — H — H ^ —  1 - 

14  33  1DTALSI29  24  33  31  27  1 

(?»hrip)  >  M  5.2 

Modify  assignmait  to  yard  INGALLS 

(Blanks  denote  no  change;  use  zero  for  assignment  deletion) 
Period:!  123456789 
Shipclass  Ti 86  87  88  89  90  91  92  93  94 

2  OS-47  12  2  2  1 


(?-help)  >  A  8 

Make  new  assignnait  for  yard  #  8,  NNEWS 

Period:!  123456789 
Shipclass  T!86  87  88  89  90  91  92  93  94 


C7N-68 

(?«help)  >  + 
(?*help)  >  t 


On  the  new  page  JOHN  needs  to  add  a  yard  that  doesn't 
appear  at  all,  TODD  LA.  A  plain  Add  ("A")  command  with  no  num¬ 
bers  after  it  initiates  this  process.  JOHN  is  first  prompted  for 
the  name  of  the  yard,  and  then  for  the  first  assignment  in  the 
yard  in  the  usual  fashion. 

Notice  on  this  page  that  several  of  the  ship  classes  have 
lower-case  characters  following  their  names,  like  "c"  after  MTS 
in  the  NNEWS  yard.  These  characters  indicate  that  the  work  being 
done  on  these  classes  is  something  other  than  new  construction  (a 
blank,  the  default,  indicates  new  construction).  The  ”c”  stands 
for  conversion,  "s"  for  SLEP,  and  "r"  for  reactivation.  It  is 
important  to  know  that  the  assigner  is  capable  of  generating 
schedules  only  for  what  are  called  "new  construction-type  jobs”, 
which  at  present  are  limited  to  new  construction,  conversions, 
and  reactivations.  It  can  read  "repair- type  job"  schedules  from 
the  repair  job  data  base  and  display  them  in  the  assigner  format, 
but  any  changes  made  to,  e.g.,  SLEP  assignment  lines  will  not  be 
saved. 

JOHN  asks  that  the  current  page  be  re-displayed  by  givinq 
the  "&"  command. 
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Scenario:  1X30  ASSIGNMENTS* 

3&ird  Period:!  123456789 
Shipclass  TI86  87  88  89  90  91  92  93  94 


1  (yN-68 


3  SSN-688 
PENNS  IP 

1  LED-4 

2  T-ACS 

3  T-AVB 


foge  3 A  Time  in:  FISCYR 


1  MCM-1 


1  CV-63  si  1  1 

TROMIA  #121 — t — I — 4 — I — I — I — J — I — I- 

1  T-AGOS-1  I  3 

TOED  SEA  #13  I  — I 1 — H-4— » — t— I  ¥—  I  - 

1  AEDM  I  11 

(more)  I — • — -» — -t—t — i — i — i — i — j- 

14  34  TOTALS  130  24  33  34  27  1 

(?»heLp)  >  A 

Give  yard  name  please  (Type  to  cancel)  > 

Make  new  assignment  for  yard  #13 »  TOOD  LA 
Period:!  123456789 
Shipclass  T! 86  87  88  89  90  91  92  93  94 


DOG-51 

FI  2  2  2 

(?»hd.p)  >  k 

JOHN'S  Strategy  in  making  these  changes  has  been  to  add 
assignments  only  in  those  classes  which  he  guesses  to  be  the 
binding  constraint  on  formation  of  new  carrier  battle  groups.  He 
is  assuming  that  the  FIXIT  scenario,  from  which  he  took  the  POM 
he  has  been  building  on,  was  a  15-carrier  battle  group  scenario, 
and  that  a  battle  group  requires  1  carrier,  1  cruiser,  and  4 
DDGs.  These  assumptions  are  only  as  correct  as  JOHN'S  knowledge 
of  the  FIXIT  scenario,  which  includes  records  of  historical  and 
current  jobs  as  well  as  the  projected  jobs  he  has  just  inspected 
as  changed. 

This  dependency  of  an  ALIAS  analysis  on  a  broad  range  of 
data  base  data,  a  fact  which  results  from  the  fundamental  depen¬ 
dency  of  ship  acquisition  program  analysis  on  lots  of  data,  is 
one  of  the  most  difficult  features  of  ALIAS  to  get  used  to.  If 
part  of  the  data  in  a  scenario  you  are  working  with  is  in  error, 
or  is  merely  not  what  you  think  it  is,  your  results  are  likely  to 
be  affected.  This  is  why  JOHN  created  a  new  scenario  for  this 

sample  session  rather  than  just  using  FIXIT - the  owner  of  FIXIT 

would  have  returned  to  find  his  data  changed,  perhaps  in  subtle 
ways  that  would  not  show  up  for  a  while.  It  is  thus  important 
that  all  ALIAS  users  exercise  restraint  in  making  changes  to 
scenarios  not  their  own. 

JOHN  inspects  the  assigner  page  and  is  satisfied.  He  gives 
the  Quit  ("Q")  command,  which  triggers  the  assigner' s  schedule 
creation  and  update  pass. 
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The  process  of  creating  complete  schedules  from  the  assign¬ 
ments  and  storing  them  in  the  data  base  is  rather  time  consuming# 
so  the  assigner  asks  JOHN  if  he  wants  to  skip  it.  He  might  want 
to  skip  it  if  he  had  run  the  assigner  only  to  inspect  the  POM# 
and  had  made  no  changes.  Since  he  wants  his  changes  implemented# 
though#  he  cannot  skip  it  this  time. 

The  assigner  lists  the  yards  as  it  processes  their  assign¬ 
ments  to  give  an  idea  of  its  progress.  Notice  that  it  issues  a 
warning  message  in  the  middl.e  of  listing  the  yards#  to  the  effect 
that  it  cannot  find  a  ^ob  description  for  the  lead  LSD-49  at 
Avondale.  It  says  it  xs  using  the  job  description  for  construc¬ 
tion  of  an  "ORDPOL"  (ordinary  follow)  LSD-49  instead.  If  you 
look  back  a  few  pages  at  the  assignments  in  the  Avondale  yard  you 
will  see  that,an  ''L"  appeared  in  the  fiscal  1988  column  of  LSD-49 
assignments#  indicating  that  one  of  the  two  awards  in  that  year 
will  be  for  a  lead  ship. 

ALIAS  differentiates  among  jobs  by  this  concept  of  "series 
type".  When  the  assigner  makes  up  a  schedule  for  a  lead  ship#  it 
expects  to  find  a  job  description  for  lead  ships  of  that  class. 

If  it  cannot  find  one#  it  uses  the  ordinary  follow  job  descrip¬ 
tion  instead#  issuing  a  warning  so  the  user  knows  what's  hap¬ 
pening. 

There  are  a  couple  of  reasons  wly  this  message  might  be 
appearing  for  JOHN.  One  is  that  there  may  be  no  difference 
between  lead  and  follow  LSD-49  construction  jobs?  in  such  a  case# 
the  owner  of  the  FIXIT  scenario  (where  JOHN  got  his  POM)  may  not 
have  bothered  to  put  in  a  lead  job  description.  Alternatively# 
the  FIXIT  owner  may  have  put  in  the  lead  LSD-49  schedule  manually 
using  the  Data  Base  Updating  system#  and  may  have  forgotten  to 
enter  a  job  description  for  it.  Any  schedule  can  be  entered 
manually - job  descriptions  are  required  only  by  the  assigner. 

In  any  case#  JOHN  makes  a  mental  note  of  the  message# 
resolving  to  check  out  the  LSD-49  job  descriptions. 

When  schedule  creation  completes  JOHN  is  returned  to  the 
menu  he  called  the  assigner  from.  He  enters  the  "/"  command#  the 
meaning  of  which  is  "pop  to  the  topmost  menu". 


Ihe  assigner  will  now  update  ship  schedjd.es  for  tiie  current  scenario. 

Only  projected  ship  schedules  will  be  updated.  Any  changes  made 
during  this  session  which  imply  changes  to  historical  or  current 
job  s^edUles  will  be  ignored. 

If  you  made  NO  CHANSES,  or  if  you  want  your  changes  DISCARDED, 
considerable  time  can  be  saved  ty  skipp^g  this  update.  If  you 
do  skip  it,  aiy  changes  you  have  made  will  be  lost. 

Do  you  want  to  skip  the  update?  N 


Opening  data  base  files  for  update, 
l^s^ting  projected  ships  data  base. 

Updating  schedules  for  yard  /VCNDALE 

UNABLE  TD  FIND  JCB  DESOUPnCN  INFO  FOR  CLASS  I.£D-49 

^  SERIES  TYPE  LEAD  USQG  SStlES  TXFE  CRDFCL  INSTEAD 

Updating  schedules  for  yard  BIW 

Updating  schedules  for  yard  S  GROT 

Updating  schedules  for  yard  GDQ 

Updating  schedules  for  yard  INSAELS 

Updating  schedules  for  yard  MARINET 

{^dating  schedules  for  yard  NASSOO 

Updating  schedules  for  yard  NNQ^S 

Updating  schedules  for  yard  PENNSIIP 

Updating  schedules  for  yard  PETERSCN 

Updating  schedules  for  yard  FH  NSY 

Updating  schedules  for  yeurd  TAQOMA 

Updating  schedules  for  yard  TODD  LA 

l^idatlng  schedules  for  yard  TODD  SEA 

Updating  schedules  for  yard  UNKBLDR 

l^xiating  hull  numbers  in  schedules. 

Upciate  Ccmplete.  DispI^  buffers  purged.  Qosing  IX. 


///////////////////////////////////////////////////////////////////////// 

Menu  is  ASSIGN  *  ALIAS  COMMAND  SYSTEM  *  Scenario  is  DEMO 


MANJ^tt.  ASSIGNER  SPEaFICATIONS 

1.  ASSIGNER  INITIALIZiVnGN  PARAMETERS 

2.  EXECUTE  THE  ASSIGNER 


In  the  Command  System  the  topmost  menu  is  the  one  first 
displayed  when  the  ALIAS  Core  started  up.  Getting  to  this  menu 

is  a  common  act,  since  it  is  the  starting  point  for  any  action - 

that's  why  there  is  a  special  command  for  doing  so. 

Having  made  his  rough“CUt  changes  to  the  POM,  JOHN  is  ready 
to  see  if  17  carrier  battle  groups  will  result.  The  Force  Level 
Report  Generator  is  the  tool  for  finding  this  out,  so  he  chooses 
option  5. 

Oopsl  He's  forgotten  something,  and  must  go  back  to  the 
top  menu  again. 


*  OOMHAND  SYS1EM  *  Scenario  is  CEMO 


Menu  is  1DP 


qOP  PLU&  COMMAND  MENU 

1.  CUSn)MIZE  USER  Ql^IRCMMEllT 

2.  CAUi  NON>ALIAS  FROCESSQRS 

3 .  DATA  BASE  UTDATINS  SYSTEM 

4.  MAHJAL  ASSIGNHEXrr  EDITOR 

5.  FORCE  LB/tL  REPORT  GENERATOR 

6.  SCENARIO  (SOIOEl/MAKEUP  S^flSlEM 


COM4AND:  5 


///////////////,///////////////////////////////////////////////////////// 


Menu  is  ELRPT3  *  ALIAS  COMMAND  SYSTEM  *  Scenario  is  EEMO 


FORCE  LEVEL  GENERATOR 

1.  FORCE  LEVOi  REPORT  INITIALIZAnON  PARAMEIERS 

2.  EXECUIE  FCRCE  REPORT  GENERATOR 

3 .  PREPARE  BATILE  GROUP  REPORT 


He  has  to  designate  which  printer  he  wants  the  report  to 
come  out  on.  The  printer  designation  is  part  of  his  "user 
environment”r  so  he  chooses  the  "Customize  User  Environment"  and 
then  the  "Environment  Parameters"  options. 


» 


OOP  LEVEL  ALIAS  COMMAND  HE3AJ 
OISIDMIZE  USEK  ENVIPCNMEIIT 
CALL  NOl-^^IAS  PBOCESSOR5 
DATA  BASE  UPDATINS  SYSTEM 
MANUAL  ASSIGNMENT  EDITOR 
FORCE  LEVEL  REPORT  GENERATOR 
SCENARIO  CHOIOE/MAKEDP  SYSTEM 


COMMAND:  1 


///////////////////////////////////////////////////////////////////////// 


Menu  is  EIVIRC 


*  M,IAS  COMMAND  SYSTEM  *  Scenario  is  DEMO 


1.  ENVIRONMENT  PARAMETERS 

2.  SET  LPRiTS  (DEBUS  SWITCHES) 


OOmAND:  1 
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There  are  three  things  that  can  be  configured  by  setting 
Environment  parameters.  The  type  of  terminal  you  are  using  is 
usually  detected  automatically  by  ^lASr  but  if  it  guesses  wrong 
you  can  override  its  guess  by  setting  parameter  1  to  the  proper 
type.  If  ALIAS  has  your  terminal  type  wrong  it  will  be  unable  to 
clear  the  display  or  manage  f ill-in-the-blank  screens  for  you. 

When  ALIAS  prints  a  report,  it  generally  sends  it  to  the 
printer  specified  by  the  "DEVICE  TO  PRINT  TO"  parameter.  DAISY 
is  the  SEA  90  daisy  wheel  printer,  PRINTER  the  fast  SEA  90  dot 
matrix  printer,  and  LP  the  PMS  392  line  printer.  JOHN  wants  his 
output  on  the  fast  dot  matrix,  so  he  sets  option  2  to  PRINTER 
(notice  he  only  has  to  specify  the  first  few  letters;  the  Command 
system  figures  out  what  he  means) . 

Once  he  has  made  this  setting  ALIAS  will  remember  it.  He 
will  not  need  to  come  back  to  the  Environment  Parameters  menu 
until  he  changes  scenarios  (parameters  are  always  a  part  of  a 
scenario,  so  if  you  work  with  a  different  one  they  may  be  dif¬ 
ferent)  or  until  he  wants  to  make  a  change. 

The  "PRINT  COMMANDS  ON  MENUS?"  parameter  is  a  good  one  to 
set  to  "YES"  if  you  are  a  new  ALIAS  user.  Remember  how  the  first 
few  menus  in  this  sample  session,  the  ones  where  the  scenario  was 
being  chosen/created,  had  a  list  of  the  most-used  commands 
printed  at  the  top?  Such  a  list  will  appear  at  the  top  of  all 
Command  System  menus  if  this  parameter  is  set  to  "YES".  Some 
users  set  it  to  "NO"  so  that  the  menus  are  typed  faster  on  the 
screen. 


Having  made  his  setting,  JOHN  pops  back  to  the  top  menu  and 
then  picks  the  force  report  option  again. 
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Menu  is  EIVCN 


*  ALIAS  COMMAND  SYSTEM  *  Scenario  is  DEMO 


In  the  Force  Level  choice  menu#  JOHN  decides  he  had  better 
look  at  the  parameters  which  will  control  the  report  generators' 
operation^  since  the  values  he  inherited  from  FIXIT  may  not  be  to 
his  liking.  He  chooses  option  1  to  bring  up  the  parameter  menu. 

When  KEEP  REPORT  ON-LINE  is  set  to  YES,  the  report  gener¬ 
ators  will  write  their  output  to  a  disk  file  as  well  as  to  the 
designated  printer.  This  makes  it  possible  to  edit  the  report 
output. 

The  REPORT  START  DATE  and  REPORT  END  DATE  parameters  deter¬ 
mine  the  period  of  time  that  reports  should  be  generated  for.  In 
combination  with  TIME  PERIOD  LENGTHr  they  determine  the  number  of 
periods/columns  that  will  appear  on  the  output.  Note  that  no 
force  report  may  have  more  than  20  periods,  since  that  is  the 
most  that  can  fit  on  a  132  column  printer  page. 

The  RETIRE  SHIPS  BY  parameter  controls  how  ship  retirement 
dates  are  computed.  If  DATE,  the  report  generators  will  use  any 
retirement  dates  they  find  in  the  data  base,  and  a  table  of  stan¬ 
dard  service  lives  for  ships  with  no  retirement  date  specified. 

If  LIFE,  the  table  of  standard  service  lives  is  used  even  for 
ships  with  specified  retirement  dates,  as  long  as  the  dates  are 
after  the  date  the  report  is  being  run  (i.e.  ships  already  out  of 
the  force  cannot  be  un-retired  by  this  setting) .  Hie  purpose  of 
the  LIFE  option  is  to  allow  studies  of  service  life  variations  to 
be  conducted  without  having  to  change  those  retirement  dates 
which  are  specified. 

Each  ship  will  retire  within  a  given  period,  say  within  a 
calendar  year.  The  IN  FORCE  DAY  parameter  specifies  the  rule  by 
which  it  is  decided  if  the  ship  is  counted  in  the  force  that 
period.  If  END  it  is  not,  if  BEGIN  it  is. 

PROGRAM  MILESTONE  is  complicated  and  not  of  interest  during 
this  sample  session,  so  discussion  of  it  will  be  postponed.  OUT 
OF  FORCE  REPAIR  JOBS  is  a  gate  to  a  list  of  job  type  codes  for 
repair  jobs  which  cause  a  ship  to  be  temporarily  out  of  the 
force. 

JOHN  decides  he  wants  the  report  to  cover  1986-1999,  and 
that  he  wants  a  look  at  the  list  represented  by  parameter  8.  The 
way  to  bring  up  the  list  is  to  re-set  its  value  to  "LIST"  (8=L  is 
a  shorthand  command  for  S^LIST) . 
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Menu  is  ELRPIG  *  GOfMAND  SYSTEM  *  Scenario  is  EEMO 


force  LB^EL  GEMESATOR 

1.  EQRCB  LEVQ,  RBEQRT  INITIALIZATZON  EARAME^IERS 

2.  EXECUTE  EXSCE  REFGRT  GEMB^TOR 

3 .  PREPARE  BATTLE  GROUP  REPORT 

OOMVVMD:  1 


///////////////////////////////////////////////////////////////////////// 


M^u  is  FLREET 


*  i^IAS  COMMAND  SYSIEM  *  Scenario  is  DEMO 


FORCE  LE7EL  AND  BAmSSRCUP  REPORT  GENBU^TCR  PARAMETERS 

KEEP  REPORT  GN-LINE 

=  YES 

(YESrNO) 

REPORT  START  DATE 

-  V  V1986 

(MVto/YYYY) 

REPORT  END  DATE 

»  iy3V2005 

(MVTDD/YYYY) 

RETIRE  SHIPS  BY 

»  LIFE 

(LIFErDATE) 

TIME  PBIIOD  LENGTH 

»  GALYR 

(DAYr  WEEKr  MONTH,  QTR,  CALYR) 

IN  EXXKE  DAY 

«  END 

(BEGINrEND) 

EROGRAM  NILESTDNE 

«  APEROP 

(APFROP,/NDrCELW) 

OUT  OF  FORCE  REPAIR  JOBS 

»  LIST 

(ALI/LIST) 

COfflAND;  3-12/31/1999 

COffAMD:  8-L 

There  are  only  three  repair  job  type  codes  listed  as  part 
of  the  DEMO  scenario,  and  all  of  them  are  "off  the  list.  "On" 
list  members  have  asterisks  next  to  their  names,  and  there  are  no 
asterisks.  JOHN  decides  he  wants  any  ships  undergoing  SLEPs  to 
not  be  counted  as  deployable,  so  he  must  turn  on  the  list  member 
named  SLEP.  To  do  so,  he  need  only  enter  its  number,  3  (if  it 
was  on  and  he  wanted  it  off,  he  would  also  enter  "S”;  giving  a 
list  member's  number  is  like  flipping  a  toggle  switch). 

After  making  the  change,  JOHN  asks  to  go  back  to  the 
parameter  menu;  when  he  gets  there,  he  asks  to  go  back  to  the 
Force  Level  choice  menu. 


Menu  is  ELREFT 


*  iS.IAS  COMMAND  SYSIEM  *  Scenario  is  DEMO 


_ REPAIR  JCBS  IHAT  REMO^  A  fflIP  FROM  PCRO:  DDRIN3  EXECDTIOK 

1.  REFUEL  3.  gJgP 

2.  REPAIR 

GOmAND:  3 
GOMAND:  ^ 

Saving  list  on/off  settings... 


///////////////////////////////////////////////////////////////////////// 


Menu  is  FLREFT  *  i^lAS  COMMAND  SYSTEM  *  Scenario  is  DEMO 

FCRCE  LBm,  AND  BATILEGROUP  REPORT  GENERATOR  PARAMETERS 

1.  KEEP  REPORT  ON-UNE  »  YES  (YES,  NO) 

2.  REPORT  START  DME  •  1/  1/1986  (MVT®/fey) 

3.  REPORT  END  DATE  «  1^31/1999  (MVtt)/YYYY) 

4.  RETIRE  SHIPS  BY  «  LIFE  (LIFErDAOE) 

5.  TIME  PERIOD  LENGTH  =  CALYR  (DAY,  WEEK,  MONTH,  Q1R,CALYR) 

6.  IN  PCRO:  DAY  ■  END  (BBGIN,END) 

7.  EROGRAM  MILESTraJE  *  APEROP  (APPROP,AWD,DELIV) 

8.  OUT  OF  FORCE  REPAIR  JOBS  «  LIST  (AUAlST) 


OOMiAND:  * 

Saving  parameter  settings 


He  is  ready  to  run  the  report  now.  He  wants  a  battle  group 
report,  which  will  give  force  levels  in  terms  of  numbers  of 
deployable  battle  groups.  The  alternative  is  a  "raw"  force  level 
report  giving  the  number  of  ships  of  each  type  avail 2ible  in  each 
period.  To  get  the  battle  group  report,  he  chooses  option  3. 
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1.  FORCE  LEVEL  REPORT  INITIALIZAnON  PARAMETERS 

2.  EXECUTE  FORCE  REPORT  GENERATOR 

3 .  PREPARE  BATTLE  GROUP  REPCXtT 

GOmAND:  3 


///////////////////////////////////////////////////////////////////////// 


LF  ■  ^  ■  IP  J' 


The  first  thing  the  battle  group  report  generator  does  is 
ask  for  the  name  of  a  "FORMAT  CONTROL  PILE".  The  force  level 
report  generators  are  unusual  among  ALIAS  modules  in  that  they 
require  more  input  than  parameters,  lists,  and  data  base  values. 

I  The  format  control  file  is  where  you  specify  exactly  what  you  "  j 

want  on  the  report,  and  how  you  want  it  placed  on  the  pages.  We  T 
will  look  at  such  a  file  in  detail  later  in  the  session.  For 
now,  JOHN  has  decided  to  use  the  one  called  BGPOM86  in  the 
.PMTFIL  group. 

i  The  report  generator  then  complains  that  the  file  FLREPT  i 

exists  in  the  log-on  group,  i.e.  in  the  file  directory  which 
holds  JOHN'S  personal  files.  JOHN  had  left  the  KEEP  REPORT  ON¬ 
LINE  parameter  set  to  YES,  i.e.  he  had  specified  that  he  wanted 
the  text  of  the  report  saved  in  a  file  as  well  as  printed.  The 
.  report  generators  automatically  save  to  a  file  called  FLREPT,  j  ■ 

I  unless  they  find  that  a  file  of  that  name  (probably  holding  a  f 

report  run  earlier)  already  exists.  In  that  case  they  ask  for  an 
alternate  file  name.  JOHN  gives  BGDEMO  as  the  name  of  the  file 
to  save  into. 

The  report  generator  then  constructs  the  report  by 
'  searching  the  data  base  for  ships  active  in  the  period  specified.  • 

The  data  base  search  is  typically  very  time-consuming,  so  the  -  " 

report  generator  ^pes  out  the  names  of  the  classes  it  is  looking 
for  as  a  means  of  reporting  its  progress. 


I 


.  % 


i 


i 


3 


-I- 


starting  up  Battle  Group  Report  Generator.  ELease  stand  by. 

NAME  OF  FORIAT  OONTRX  FILE  (name.groupr  or  BGPOMB6.FIITFIL 

The  file  ELREPT  alreac^  exists  in  your  group. 

Ihe  force  lev^  modules  usually  store  reports  in  that 
file  when  you  request  that  the  report  be  seved  on  disk. 

Since  that  file  is  in  use,  what  file  would  you  like  to  store 

the  report  in?  (name  <*  8  letters,  or  /  to  not  save  r^rt) :  BGDBNO 

Opening  required  data  base  files... 

Looking  for  ships  in  data  base... 

Looking  for  class  BD-61 
Looking  for  class  aQ>16 
Looking  for  class  OG-26 
Looking  for  class  03-47 
Looking  for  class  C)SN-25 
Looking  for  class  03N-35 
Looking  for  class  03N-36 
Looking  for  class  03N-38 
Looking  for  class  G3N-9 
Looking  for  class  (y-41 
Looking  for  class  CV-59 
Looking  for  class  or-63 
Looking  for  class  CV-^ 

Looking  for  class  (yNh65 
Looking  for  class  CVN-68 
Looking  for  class  OD-963 
Looking  for  class  EDG-2 
Looking  for  class  EIX3-37 
Looking  for  class  CDG-51 
Looking  for  class  IX]G-’993 
Looking  for  class  PP-1040 
Looking  for  class  PP-1052 
Looking  for  class  FFG-1 
Looking  for  class  FFS-7 
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A  COPY  of  the  output  which  resulted  is  shown  in  the  top 
frame  opposite.  Five  types  of  "battle  group"  are  reported  on 
here:  carrier  battle  groups#  surface  action  groups,  marine 
amphibious  forces,  supply  ships  escorts,  and  convoys.  The  number 
of  each  group  deployable  in  each  year  is  given.  Ships  of  each 
type  that  were  "left  over"  after  all  the  groups  were  made  up 
(i.e.  which  were  a  member  of  no  group)  are  tot2d.led  by  type  at 
the  bottom. 

JOHN  immediately  sees  he  was  mistaken  about  the  nature  of 
the  scenario  he  started  out  with.  Not  only  does  he  not  achieve 
17  carrier  battle  groups  in  the  90 's,  the  number  achieved  all 
along  is  well  below  what  he  was  expecting.  And  yet  there  are 
plenty  of  aircraft  carriers,  in  fact  17  are  available  from  1997 
on  (add  up  the  CARRIER  BG  row  and  the  CARRIER  balance  row).  The 
problem  must  be  with  availability  of  other  ships  which  make  up  a 
battle  group.  JOHN  immediately  decides  that  DDG  availability 
must  be  the  binding  constraint,  since  there  is  a  0  balance  for 
that  ship  type  over  the  whole  period. 

Why  is  this  availeibility  unrealistically  low?  When  you  are 
faced  with  such  a  problem,  the  best  thing  to  do  is  go  ask  the 
person  whose  scenario  you  used  as  a  starting  point.  But  for  the 
purposes  of  this  sample  session,  it  will  be  more  interesting  if 
we  have  JOHN  play  detective  instead. 

There  are  only  two  reasons  why  this  can  be  happening,  he 
reasons.  One  might  be  that  somehow  the  construction  job  sched¬ 
ules  for  a  number  of  currently  active  DDG's  never  were  entered  in 
the  data  base  for  his  scenario  (the  force  level  report  generators 
look  for  those  schedules  to  determine  what  ships  enter  the  force 
when) .  The  other  reason  might  be  that  they  are  being  retired  too 
early. 


To  find  out,  JOHN  will  have  to  look  at  the  contents  of  the 
data  base.  Since  he  is  interested  in  a  fairly  significant  volume 
of  data  (construction  schedules  for  several  DDGs) ,  the  best  way 
to  look  is  with  the  RELATE  Data  Base  Management  tystem's  query 
language.  To  use  RELATE,  JOHN  will  have  to  log  on  as  JOHNR. 

When  the  battle  group  report  generator  finished  it  returned 
JOHN  to  the  force  report  choice  menu.  He  tells  ALIAS  he  wants  to 
finish  his  session  via  the  "Q"  command. 


3-42 


DEPLOYABLE  BATTLE  GROUP  PROJECTION  FOR  PON-86 
BASED  ON  SURFACE  COMBATANT  REQUIREMENTS  ONLY 
(ALL  DATA  NOTIONAL) 


CALENDAR  YEAR  1986  1987  1988  1989  1990  1991  1992  1993  1994  1995  1996  1997  1998  1999 
BATTLEGROUP 


CARRIER  BG  99997555 
SURFACE  AG 

MARINE  AF  111 

SUPPLY  ESCORT  11111111 
CONVOY  10  10  10  10  8  10  10  10 

BALANCE 


CARRIER  4  4  4  5  7  10  9  10  10  9  9  10  10  10 

BB  111111111111 

CRUISER  7777799787  5333 

DUG 

DD  2222  2  10  296 

FFG 

FF  33  33  34  34  40  40  50  40  47  37  31  26  21  16 

nniiiiuniiiiiinniiiiniunniiinnuiniiniiiiiiiiimiiiiiiiiii 

Menu  is  FLRPTG  *  ALIAS  COMMAND  SYSTEM  *  Scenario  is  DEMO 


FORCE  LEVEL  GENERATOR 

1.  FORCE  LEVEL  REPORT  INITIALIZATION  PARAMETERS 

2.  EXECUTE  FORCE  REPORT  GENERATOR 

3.  PREPARE  BATTLE  GROUP  REPORT 

COMMAND:  Q 

Are  you  sure  you  want  to  terminate  your  ALIAS  session?  Y 


6  7  7  7  7  7 

1111 

1 

10  10  9  9  9  9 


END  OF  PROGRAM 


When  he  receives  the  prompt  after  the  ALIAS  Core  pro^ 

gram  ends,  he  logs  on  as  JOHNR  using  the  same  procedure  as  during 
his  initial  log-in.  Then  he  runs  RELATE,  the  DBMS.  His  first 
RELATE  command  (OPEN  FILE)  is  a  request  to  access  the  relation  in 
which  historical  construction  schedules  are  stored.  To  test  the 
first  hypothesis  about  the  "missing  DDGs"  (that  their  construc¬ 
tion  jobs  don't  appear  in  this  relation  for  the  DEMO  scenario), 
he  gives  a  SELECT  command  designed  to  return  one  record  per  DDG 
construction  job  in  ncjodat.histj.  To  get  only  one  record  per 
job,  he  asks  that  they  be  returned  UNIQUE  BY  SCENARIO, CLASS, HULL, 
COMNUM  (COMNUM  is  "commissioning  number").  To  get  only  ships 
actually  built,  he  asks  that  DATETYPE= "ACTUAL".  To  get  only  DDGs, 
he  asks  that  the  class  name  have  the  string  "DDG”  in  it  somewhere 
(MATCH (CLASS, "DDG" ) <>0) .  To  get  the  information  for  the  DEMO 
scenario  only,  he  asks  for  SCENARIO=”FIXIT" . 

Why  "FIXIT"  and  not  "DEMO"?  Because  when  JOHN  made  up  the 
DEMO  scenario,  he  answered  "NO"  to  the  question  "Will  you  want  to 
change  data  in  the  .HISTJ  group?"  By  giving  that  answer,  and 
FIXIT  as  the  name  of  the  source  scenario,  he  was  implicitly 
asking  to  use  FIXIT' s  data  "indirectly"  during  ALIAS  runs.  If  he 
had  answered  "YES",  then  a  copy  of  the  .HISTJ  data  for  FIXIT 
would  have  been  made,  with  scenario  field  values  of  DEMO. 

So  to  find  out  what  data  is  in  ncjodat.histj  for  scenario 
DEMO,  JOHN  actually  has  to  ask  what  is  there  for  scenario  FIXIT 
in  this  case.  This  is  a  subtle  point  that  it's  easy  to  forget 
about.  Later  in  the  sample  session  there  will  be  an  example  of 
how  to  find  out  about  this  "composition"  aspect  of  an  already 
existing  scenario. 

You  might  be  wondering  why  anyone  would  ever  pgf  want  their 
own  copy  of  the  data  for  all  groups,  given  this  possibility  for 
confusion.  The  answer  is  that  if  you  have  your  own  copy,  then 
you  are  responsible  for  all  the  data  updating  necessary  to  keep 
it  current  1  That  can  be  a  big  job,  especially  for  the  .CURRJ 
group,  so  it  is  almost  always  best  to  use  indirectly  the  data  for 
a  scenario  that  you  know  is  receiving  data  updating  service. 
Indirect  use  also  saves  disk  space. 


:Haj.O  JCH1IR.SEA90 

EN!EER  USER  PASSWORD: 

HP3000  /  MPE  IV  C.Ba..A2.  SAT,  OCT  20,  1984,  12:16  PM 
********************************************************** 

WEEKLY  BACK  UP  OF  FILES  IS  NCW  lAKIMG  8-  2400  FEET  REELS 
OF  lAPE  AND  LASTUG  NCRE  IRAN  2  1/2  HOURS.  IT  IS  IMPERATIVE 
IHAT  users  of  the  SYSTEM  PURGE  OLD  FILES  CEl  A  REGULAR  BASIS. 

************************************************************ 


Bulletin: 

****************************************************************** 

****************************************************************** 

*****************  j;]Q  jjgp  r.RAVR  tour  terminal  ********************* 
*****************  UNATTENDED  ********************* 

*****************  SIGN  OFF  1 1 1 1  ********************* 

****************************************************************** 

****************************************************************** 


END  OF  PROGRAM 
ZBOJOR 

Gcnine±  MAKE  SUIS;  HP2934A  IS  TUINED  BEFORE  FRinting, 

Ccnment  OTHERWISE  YOU'LL  LOSE  SPOaER  OWNERSHIP. 

FILE  rdbecat.  pub.  s/s^cdbecat.  pub.  relate 

FILE  rdbh^p.pub.^s«rdbheLp.pub.relate 

FILE  grecat.pub.sy^  grecat.  pub.  relate 

FILE  plotter ;devB50 

FILE  rdblist;dev^8;cctl 

RUN  relate,  pub.  relate;!  ib^;maxdata=31000 

RELATE/3000  V4,40A  SAT,  OCT  20,  1984,  12:16  IM  (C)  CRI 

DOPES  FILE  NGJODAT.HISTD;IIOD^SHARED 

2)  SELECT  SCEHAR10,a.ASS,HaLL,GOIinm  UNIQUE  BY  SCENARIO,  CLASS,  HULL,  GOII1UM& 
.1&)  WHERE  SCBURI{>”FIXIT*  AND  WTCS (CLASS, 'HlDG*)  <>0 

3)  PRINT  aj^,HDLL 
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After  giving  the  select  JOHN  asks  that  all  the  records 
matching  his  criteria  be  printed.  He  only  asks  for  the  CLASS  and 
HULL  fields,  but  he  gets  SCENARIO  and  COMNUN  in  the  printout  as 
well  because  those  fields  are  part  of  the  index  he  specified  in 
the  select  BY  clause. 

He  finds  that  there  are  37  DDG  construction  jobs  in  the 
relation  for  DEMO/FIXIT.  He  decides  this  is  a  reasonable  number 
and  terminates  his  RELATE  session  with  the  "//"  command. 

JOHN  could  have  been  fancier  and  given  a  select  command 
with  more  sophisticated  clauses  and  conditions  such  that  RELATE 
would  have  printed  only  the  number  "37".  Going  that  route  is  a 
good  idea  when  the  number  of  records  you  expect  is  in  the  hun¬ 
dreds,  but  it  can  be  tricky  to  get  the  select  statement  set  up 
just  right. 
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SCENARIO 

GOMNJM  OiASS 

HULL 

EIXIT 

1  EW3-2 

2 

FIXIT 

1  DDG-2 

3 

FIXET 

1  EDG-2 

4 

FIXIT 

1  EDG-2 

5 

FIXIT 

1  EXX3>2 

6 

FIXIT 

1  EDG-2 

7 

FIXIT 

1  DDG-2 

8 

FIXIT 

1  EDQ-2 

9 

FIXIT 

1  DDG-2 

10 

FIXIT 

1  COG-2 

11 

FIXIT 

1  COG-2 

12 

FIXIT 

1  DDO-2 

13 

FIXIT 

1  COG-2 

14 

FIXIT 

1  COG-2 

15 

FIXIT 

1  DOG-2 

16 

FIXIT 

1  COG-2 

17 

FIXIT 

1  DOG-2 

18 

FIXIT 

1  EDG-2 

19 

FIXET 

1  EDG-2 

20 

FIXIT 

1  EDG-2 

21 

Fixer 

1  EDG-2 

22 

FIXIT 

1  EDG-2 

23 

FIXIT 

1  EDG-2 

24 

FIXIT 

1  EDG-37 

37 

FIXIT 

1  DDG-37 

38 

FIXIT 

1  EDG-37 

39 

FIXIT 

1  DDG-37 

40 

FIXIT 

1  DDG-37 

41 

FIXIT 

1  DDG-37 

42 

Fixrr 

1  EDG-37 

43 

FIXIT 

1  EOG-37 

44 

Fixrr 

1  DDG-37 

45 

FIXIT 

1  EDG-37 

46 

FIXIT 

1  DDG-993 

993 

FIXIT 

1  DDG-993 

994 

FIXIT 

1  EDG-993 

995 

FIXIT 

1  DDG-993 

996 

37  LINES 

PRINTED. 

4)// 


END  OF  PROGRAM 


To  be  thorough,  JOHN  really  should  have  gone  and  checked 
the  second  hypothesis  (DDGs  retiring  too  early)  before  leaving 
RELATE,  but  he  is  so  confident  he  is  right  that  he  is  going  to  go 
fix  the  problem  right  away.  Since  he  had  specified  that  ships  be 
retired  according  to  their  standard  service  life  in  the  force 
level  parameters  menu,  he  is  sure  that  the  service  life  specifi¬ 
cation  for  the  DDGs  must  be  too  short.  He  knows  that  these  ships 
are  slated  for  SLEFs  in  the  near  future,  but  that  actual  projec¬ 
tions  of  the  SLEP  jobs  probably  have  not  been  entered  in  the 
repair  jobs  data  base.  He  can  simulate  the  effect  of  the  SLEP 
jobs  by  just  increasing  the  standard  service  lives. 

To  change  the  service  lives  he  must  get  back  into  ALIAS. 
Although  JOHN  can  look  at  any  data  in  the  data  base  using  RELATE, 
he  cannot  change  any  that  way.  All  changes  must  be  made  using 
the  ALIAS  Data  Base  Updating  ^stem  (DBU) .  The  DBU  makes  sure 
that  all  data  base  entries  and  changes  are  validated.  Without 

validation,  honest  mistakes  would  rapidly  render  the  ALIAS  data 
base  unusable. 

So  JOHN  logs  on  with  his  JOHNA  user  neune  again,  and  gives 
the  ALIAS  command  when  he  receives  the  colon  prompt. 


I 

i 


i 


I 


3- 


:HELLO  JGH10USBA90 
enter  user  PASSWCRD: 

HP3000  /  HPE  3V  C.B1.A2.  SAT,  OCT  20,  1984,  12:34  PM 
********************************************************** 
WEEKLY  BACK  UP  OF  FILES  IS  NCW  TAKING  8>  2400  FEET  REXLS 
OF  13^  MJD  LASTING  MCRE  IHAN  2  1/2  HOURS.  IT  IS  IMPERATIVE 
IHAT  USERS  OF  THE  SYSTEM  HJFGE  OLD  FILES  CN  A  REGULAR  BASIS. 
************************************************************ 


Bulletin: 

****************************************************************** 
****************************************************************** 
*****************  20  NOT  LEAVE  YOUR  TERMINAL  ********************* 
*****************  UNATTENDED  *********.************ 

*****************  SIGN  OFF  nil  ********************* 
****************************************************************** 
****************************************************************** 


end  of  program 
:AL1AS 


********************************** 
*  * 

*  WELCOME  TO  ALIAS  * 

*  VERSION  1.0  * 

********************************** 


>  SYSTEM  START-UP  IN  PROGRESS: 
-Loading  core  ^steni. .. 
-Connecting  to  data  base... 
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This  time  when  ALIAS  asks  what  scenario  he  wants  to  use,  he 
can  just  say  "DEMO”.  He  doesn't  have  to  create  scenario  DEMO 
again.  Once  a  scenario  is  created,  it  stays  in  place  until  its 
creator  or  the  Data  Base  Administrator  deletes  it. 


current  scenario  is 


Scencurio  choice  onions  include: 

?  provides  help 

§  lists  existing  scenarios 

@naine  lists  the  compositicxi 
of  the  'name'  scenario 
name  makes  the  'name'  scenario 
your  current  scenario 


^  exits  scenario  choice  system 

+  moves  you  into  scenario 

creation  m»u 

&  re-displays  this  menu 


SCENARIO  CHOICE  MENU 

Name  of  scenario  to  use,  or  Gcranand  character:  DBMD 


********************************** 
*  * 

*  LOADOG  PARAMETERS  * 

*  * 

********************************** 
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In  the  Conunand  System  top  menur  JOHN  asks  to  use  the  DBU. 

If  you  are  following  alongr  it  is  important  that  ALIAS  have  made 
a  correct  guess  concerning  the  type  of  terminal  type  you  are 
using  before  you  try  and  run  the  DBU.  If  ALIAS  did  not  clear 
your  display  before  presenting  the  top  Command  ^stem  menu^  it  s 
guess  is  certainly  wrong  and  you  must  go  and  correct  it  in  the 
User  Environment  area. 

After  a  (probably  long)  delay  the  MASTER  screen  of  the  DBU 
is  displayed.  You  should  know  that  this  DBU  startup  delay  is  a 
one-time  cost  for  any  given  ALIAS  run.  When  you  leave  the  DBU, 
it  will  be  put  on  "hold"  and  will  be  immediately  ready  for  your 
later  use. 

Though  not  evident  on  the  paper  copy,  the  MASTER  screen  is 
subtly  different  from  the  TOP  Command  menu.  If  you  are  looking 
at  it  on  your  display,  you  will  notice  that  the  area  after  the 
COMMAND  prompt  on  the  display  is  in  inverse  video;  it  is  a 
f ill-in-the-blank  area.  This  makes  MASTER  a  screen,  not  a  menu, 
even  though  functionally  it  is  a  menu  of  nimibered  choices  just 
like  TOP.  As  you  become  more  familiar  with  ALIAS  you  will  find 
that  your  command  options  are  somewhat  different  in  screens  than 
in  menus. 

Notice  that  the  fact  that  the  DBU  is  a  new  and  different 
context  is  indicated  by  the  "ALIAS  DATA  BASE  UPDATE  SYSTEM"  title 
at  the  top  of  the  screen.  As  usual,  when  the  title  at  the  top  is 
different,  the  rules  will  be  somewhat  different. 

The  MASTER  menu  presents  different  types  of  data  that  can 
be  accessed  and  updated  with  the  DBU.  JOHN  wants  to  change 
something  having  to  do  with  entire  DDG  ship  classes  (their 
service  lives),  so  he  chooses  option  1  by  hitting  the  "1"  key 
followed  by  the  carriage  return  key. 
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Menu  is  TOP 


*  /ffilAS  CDMMftND  SYSTEM  *  Scenario  is  DEMO 


TOP  LEVEL  OCMIAMD  MENU 

1.  CUSTOMIZE  USER  EI^IRCNMENT 

2.  CALL  NON-ALIAS  FPOCESSQRS 

3.  DATA  BASE  UPDATINS  SYSTEM 

4.  MANUAL  ASSIGNMENT  EDITOR 

5.  Et3RCE  LEVEL  REPORT  GENE2UYIOR 

6.  SCENARIO  (BOICE/JftKBUP  SYSTEM 

OOfflAMD:  3 

Starting  up  Data  Base  Updater.  Expect  a  dele^  of  several  minutes. 
Data  maintenance  module  start  up  no#  in  progress. . . 

Connecting  to  data  dictionary... 

Connecting  to  the  legal  values  referaice  library... 


/////////////////////////////////////////////////////////////////// 


SCREEN  IS:  MASTER  SCQIARIO  IS:  EEMO 

?  for  help  AIAS  DATA  BASE  UPDATE  SYSTEM  _  "NAME  ju 

"  •  "  Ml  choose  a  screen  to  use  fcy  nunber  or  >NAME 

QOMAND:  1 

1.  SIP  CXASSES 

2.  SIP  JCB  TYPES 

3.  SIP  JCB  SCHEDULES 

4.  SIP  YARDS 

5.  SIP  DEACTIVATICNS 

6.  DATA  DICTIONARY  UPDATING  SYSTEM 


I  ■  'No  data  mey  be  changed  nere^""» 

Please  pLaoe  a  ocnmand  or  cption  nunber  after  QDMAfflD 


ailU 
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A  new  screen  is  disple^ed,  again  offering  choices.  JOHN 
wants  to  change  a  class  characteristic/  not  schedule  planning 
factors  (the  job  descriptions  the  assigner  uses  in  making  up 
schedules)  for  a  classr  so  again  he  chooses  option  1. 

The  CLASS. CHARS  data  screen  is  presented.  Its  function  is 
to  display  and  allow  changes  of  class  descriptions.  It  is 
concerned  with  any  data  that  applies  to  a  class  as  a  whole/  which 
is  generally  pli^sical  data.  In  the  right  middle/  though/  there 
is  an  area  labeled  SHIP  LIFE  with  a  field  labeled  "Standard 
Service  Time  After  Delivery".  This  is  the  only  field  JOHN  will 
be  concerned  with. 

If  you  are  running  a  sample  session  as  well  as  reading 
along  you  will  note  that  the  CLASS. CHARS  screen  looks  much  dif> 
ferent  on  the  display  than  it  does  on  paper.  This  is  because  all 
the  screen  enhancements  (the  inverse  video  and  underlining)  do 
not  show  on  the  paper.  If  you  are  just  reading  be  aware  that 
there  are  clearly  marked  data-entry  "windows"  or  "blanks"  after 
each  label  (a  whole  matrix  of  rows  and  columns  in  the  SHIP  SIZE 
area)  to  tell  the  user  where  data  should  go. 

JOHN  wants  to  bring  up  the  class  descriptions  for  the  two 
older  DDG  ship  classes  that  showed  up  on  his  RELATE  output/  DDG-2 
and  DOG- 37.  There  are  two  ways  he  can  do  this:  he  can  work  his 
way  through  all  the  ship  classes  (in  alphabetical  order)  using 
the  N  (next)  command/  or  he  can  get  directly  to  the  DDG  records 
using  the  S  (search)  command. 

The  latter  is  much  quicker  for  JOHN'S  purposes.  To  use  it/ 
he  just  puts  "S"  in  the  COMMAND  field/  "DDG"  in  the  CLASS  field/ 
and  hits  the  return  key.  If  you  are  working  along  at  the  ter¬ 
minal/  you  move  between  fields  using  the  TAB  key.  Note  that  the 
arrow  keys  on  HP  terminals  will  not  work  for  these  screens/  but 
you  may  be  able  to  use  the  terminal's  function  keys  to  achieve 
the  same  effects. 

The  effect  of  the  S  command  is  to  set  the  DBU  up  to  show 
you  only  records  whose  fields  all  match  the  values  you  have  spec¬ 
ified  by  filling  them  in  on  the  screen.  There  is  no  limit  to  the 
number  of  fields  you  can  fill  in.  The  more  fields  you  fill  in/ 
and  the  more  precisely  you  fill  in  each  one/  the  more  precisely 
the  records  which  are  returned  will  match  the  target  in  your  mind 
(but  if  you're  not  sure  of  a  value/  don't  fill  it  in/  because  the 
DBU  will  tell  you  it  can't  find  anything  if  such  a  value  doesn't 
exist  in  the  data  base) . 

There's  a  catch  to  using  the  S  command.  You  have  to  be 
sure  that  ALL  the  fields  on  the  screen  are  blank  EXCEPT  for  the 
ones  you  fill  in  as  targets/  including  the  "Entry  Date"  and 
"Entry  By"  fields  at  the  bottom  right  (which  you  can't  change). 

To  make  sure  you  start  with  a  clean  slate/  give  the  "K"  (clear) 
command  before  you  start  your  set-up  for  S.  The  bottom  frame  at 
the  right  shows  JOHN  about  to  hit  the  return  key  to  execute  the  K 
command. 
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SaiEEN  IS:  CLASS_MEIU 


SCENARIO  IS:  I£MO 


?  for  help 


i^IAS  DAXA  BASE  UPDAOE  SYSIEM 
-choose  a  scre^  to  use  ty  nunber  or 

CDMIAND:  1 

1.  CLASS  (SARACTERISnCS 

2.  SCBECULE  ILANNINS  FACTORS 


■NAME  jumps 


I  I  -irn-Triimni  rir»  i  'rNp  data  10^  bs  Changed  here  — 

Hease  pLaoe  a  cemaand  or  optiem  nimber  after  OOMAftO)  and  press  RETIIIIM 


/////////////////////////////////////////////////////////////////// 


SCREEN  IS:  CLASS  CHARS 


LATEST  DATA 


SCENARIO  IS:  DEMO 


?  for  help 


Qass  Name: 
Nane  for  Reports: 


ALIAS  DATA  BASE  UFDATE  SYSTEM 
—Ship  Class  Characteristics— 


sNAME  junps 


OOMIAND:  K 


owner :  USN 


SHIP  SIZE 


SHIP  LIFE 


Length  Beam  Height  Draft  Oisplacenient  Standard  Service  Time 
Waterl  ine :  After  Del  ivery : 

Overall:  in  Time  Units:  MONTHS 

At  Launch:  Data  Source 

Light :  Data  Date 

Full  Load:  Entry  Date 

Entry  By 

if  ■■iTTiiT.  Ill  r Your  priveleges  in  this  screen  are:  inspect'' — ^  -n  1 1  r  -rr^ 

Place  a  cemnand  after  OOMMMQ)  and  press  RETURN 
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The  top  frame  at  the  right  shows  the  display  after  K  has 
been  executed.  Notice  that  the  vad.ues  which  were  showing  in  the 
"Owner”  and  "Time  Units"  fields  on  the  previous  frame  have  been 
erased. 

JOHN  is  then  free  to  fill  "DDG"  into  the  class  field  and  to 
give  the  S  command. 
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SCREEN  IS:  <XASS.(SARS 


?  for  hdp 


latest  data 


SCENARIO  IS:  DEH) 


ALIAS  DATA  BASE  UPDATE  SYSTEM 
»Ship  Qass  Characteristic^**^ 

QOMAND: 


•NAME  3  imp 


Class  Name: 


owner: 


Name  for  Reports: 


Slip  SIZE 


SBIP  LIEE 


Length  Beam  Height  Draft  I^spd.aceroent  Standard  Service  Time 
Waterline:  After  Delivery: 

Overall:  in  Time  Units: 

At  Launch:  Data  Source 

Li^t:  Data  Date 

Full  Load:  Entry  Date 

Entry  By 

'  ■  '  *  ■  -Your  privileges  in  this  screen  are:  inspect*"  ■ n  ■■  - - 

Place  a  camievid  after  COMMAND  and  press  RETUI^ 


/////////////////////////////////////////////////////////////////// 


SCREEN  IS:  CLASS  CHARS 


LATEST  DATA 


SCENARIO  IS:  DEMO 


?  for  help 


^lAS  DATA  BASE  UPDATE  SYSTEM 
»*Ship  Qass  Characteristics»" 

CLfflAND:  S 


•NAME  junps 


Qass  N^e: 


Owner: 


Nane  for  Reports: 


SHIP  SIZE 


SHIP  LIEE 


Length  Beam  Height  Draft  OispLacement  Standard  Service  Time 
Waterline:  After  Delivery: 

overall:  in  Time  Units: 

At  Launch:  Data  Source 

Li^t:  Data  Date 

Full  Load:  Entry  Date 

Entry  By 

■  I  ■!  Ti  Your  privileges  in  this  screen  are:  inspect^ ^  r  n  i  i-i--. .  — 

PLaoe  a  ccnmand  after  CD^MAND  and  press  REIUEN 


S  returns  the  first  matching  record  (if  it  can  find  one). 
The  first  match  is  on  DDG-2  in  this  case,  which  is  one  of  the  two 
classes  JOHN  is  interested  in.  The  job  description  is  rather 
incomplete,  (having  no  ship  size  information  at  alll),  but  does 
have  a  standard  service  life  specification  of  30  calendar  years. 
This  is  about  what  JOHN  expected  to  see,  since  most  ships  without 
SLEPs  last  about  this  amount  of  time. 

In  the  bottom  frame  JOHN  has  changed  the  standard  life  to 
45  years  to  simulate  the  SLEPs  he  expects,  and  has  changed  the 
Data  Source  to  "IMAGINED"  as  a  reminder  that  this  is  not  "real" 
data  (notice  that  on  the  paper  copies  of  the  screens  you  can 
distinguish  between  what  JOHN  types  and  what  ALIAS  types  by  the 
fact  that  JOHN'S  entries  are  in  bold  face'). 

He  has  just  executed  the  M  (modify)  command,  which  will 
replace  the  old  record  with  the  new  in  the  data  base,  but  is 
chagrined  to  see  an  error  message  appear  at  the  bottom  of  the 
screen:  "Scenario  security  forbids  your  making  data  changes 

here."  He  is  chagrined  because  all  along  the  screen  has  been 
telling  him  in  the  privilege- status  line  two  lines  up  that  "Your 
priveleges  in  this  screen  are:  inspect",  i.e.  that  he  can  look  at 
data  but  can' t  make  changes. 

Why  has  this  happened?  There  are  two  reasons  why  his  data 
changes  privileges  might  be  limited  in  a  screen.  One  is  that  the 
Data  Base  Administrator  may  have  set  up  security  such  that  JOHN 
is  never  able  to  change  data  in  the  CLASS^CHARS  screen.  The 
other  is  that  JOHN  may  have  set  up  his  scenario  so  he  is  using 
the  class-description  data  (stored  in  group  .MISCJ)  indirectly. 
Data  being  used  indirectly  may  not  be  changed,  since  it  really 
belongs  to  someone  else's  scenario. 

The  error  message  is  the  tip-off  that  this  is  the  case.  If 
you  look  back  to  JOHN'S  creation  of  scenario  DEMO  in  the  first 
few  pages  of  this  Section,  you  will  see  that  he  indeed  answered 
"No"  when  asked  if  he  expected  to  make  changes  to  data  in  the 
.MISCJ  group. 
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SCREEN  IS:  CLASS. CHARS 


LATEST  DMEA 


SCENARIO  IS:  DEMO 


?  for  help 


i^IAS  DATA  BASE  UPDATE  SYSTEM 
sShip  Qass  Characteristics™ 


sMAME  junps 


OOffAND: 

Qass  Name :  CD02 

Name  for  Reports: 

SHIP  SIZE 


CWner :  USN 


aJIP  LIEE 


Waterline: 

Overall: 

At  Launch: 
Light: 

Full  Load: 


I 


Length  Beam  Height  Draft  Displacement 
0  0 

0  0 


Standard  Service  Time 
After  Delivery:  30 
in  Time  Units:  CALYR 


000  Data  Source  CSDS 

000  Data  Date  3/28/1984 

0  0  0  Entry  Date  3/28/1984 

Entry  By  MARK 

=Your  privileges  in  this  screen  are:  inspect® 


Place  a  ccnUnand  after  COMMAND  and  press  RETURN 


/////////////////////////////////////////////////////////////////// 


SCREEN  IS:  CLASS. CHARS 


LATEST  DATA 


SCENARIO  IS:  DEMO 


?  for  help 


i^IAS  DATA  BASE  UPDATE  SYSTEM 
s^Ship  Qass  Character istics™= 


■NAME  junps 


Qass  Name: 
Nane  for  Reports: 


CDMAND:  N 


CDQ-2 


CWner :  USN 


SIP  SIZE 


Length  Beam 
Waterline:  0  0 

Overall ;  0  0 

At  Launch: 

Light: 

Full  Load: 


Height  Draft  Displacentent 


0 

0 

0 


0 

0 

0 


0 

0 

0 


SIP  LIFE 

Stcuidard  Service  Time 
After  Delivery:  45 
in  Time  Units:  <3ALYR 
Data  Source  IMAGINED 
Data  Date  3/28/1984 
Entry  Date  3/28/1984 
Entry  Ey  MARK 


«Tii»Ti-  -1 1  Your  privileges  in  this  screen  are:  inspect* 

Place  a  coimand  after  COMMAND  and  press  RETURN 
Scenario  security  forbids  your  making  data  changes  here. 


What's  to  be  done?  Does  JOHN  have  to  start  over?  Cer¬ 
tainly  not,  this  is  no  mote  than  a  minor  annoyance.  He  need  only 
use  the  scenario  system's  capability  to  change  scenario  composi¬ 
tions  to  convert  .MISCJ  data  for  scenario  DEMO  from  indirect  to 
direct-access  status.  To  do  this,  JOHN  asks  to  Quit  (Q)  from  the 
DBU. 

He  is  returned  to  the  Command  System  TOP  menu  (from  whence 
he  called  up  the  DBU),  and  asks  for  option  6,  the  scenario 
system. 
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2/4 


k  RD-AlSe  424  RCQUISITION  RND  LOGISTICS  INFORHRTION  RND  RNRLVSIS 
SYSTEM  (RLIRS)  USER^S  GUIDE(U>  DECISION-SCIENCE 
RPPLICRTIONS  INC  ARLINGTON  VR  H  S  CRREV  ET  RL. 

UNCLASSIFIED  21  OCT  84  DSR-G18  N880i4-82'C-e812  F/G  15/5  NL 


•  r  1  O'  3 


IS:  CLAS^CBARS 


CATE5T  DA3A 


» »:  •] 


foe  help 


Class  Name: 
Name  for  Reports: 


/OjIAS  DA3A  BASE  DFDAIE  SXS^ 
—Ship  Qass  Qaaracteristico"" 


bNahe  ^unp 


OOMAND:  Q 
CDG-2 


ewner:  USN 


Waterline: 
(derail: 
At  Launch: 
Li^t: 

Full  Load: 


£BIP  SIZE 


Length  Beam  Hei^t  Draft  E>isplacenent 


•«Your  privileges  in  this  screen  are:  inspect" 
Place  a  cemnand  after  COMMAND  and  press  REIDRN 


SHIP  LIfE 

Standard  Service  Time 
After  Delivery:  45 
in  Time  Units:  CALYB 

Data  Source  IMAG3NEZ) 
Data  Date  3/28/1984 
Qitry  Date  3/28/1984 
Entry  By  MARK  . 


/////////////////////////////////////////////////////////////////// 


Menu  is  TOP 


*  fLIAS  OOMIAND  SYSTEM  *  Scenario  is  EEMO 


TOP  LEm.  ALIAS 
CUSTOMIZE  USBl  QlVIRQNMElfr 
CAU.  NON-ALIAS  PROCESSORS 
DAXA  BASE  UPDATINS  SYSTEM 
MANJAL  ASSISIMENT  EDITOl 
FORCE  LEVEL  REPORT  GQlStMOR 
SCENARIO  CBOICE/IAKEDP  SYSTEM 


GOffAND:  6 


In  the  Command  Systems  SCEN  choice  menu^  he  wants  to  "Mod¬ 
ify  the  makeup  of  an  existing  scenario."  The  scenario  system's 
modification  menu  (stage  1)  menu  comes  up  in  response  to  his 
request  for  option  6.  Notice  that  we  are  in  yet  another  context 
here:  there  is  no  real  menu  title,  only  a  header  line  noting 
that  JOHN  is  in  the  scenario  i^stem  and  the  activity  he  is 
performing. 

In  this  "stage  1"  menu  JOHN  must  neune  the  scenario  he  wants 
to  change  the  composition  of  (which  can  be  different  from  the  one 
he  is  running).  He  wants  to  find  out  the  current  composition  of 
DEMO  before  he  chances  it,  though,  so  he  gives  the  "DEMO*  com¬ 
mand  (listed  as  "name"  at  the  top  of  the  menu  as  one  of  the 
available  service  commands) . 


*  ALIAS 


Scenario  is 


CHOOSE  A  DIFCEREUT  SCQIARIO  ID  WORK  WPIB 

(XEAIE  A  NEW  SCENARIO 

EELEIE  CDRREinLY  EXISTDC  SCSIARJOS 

LIST  GURREmLY  EXISTSG  SCENARIOS 

SEND  LIST  OF  EXISTING  SCENARIOS  ID  LINE  msnSR 

MODIFY  1HE  fAKEDP  OF  m  EXISTING  SCENARIO 


COMAND:  6 


/////////////////////////////////////////////////////////////////// 


Scenario  niodificaticm  options  include: 
?  provides  help 

@  lists  existing  scenarios 

name  specifies  the  name  of  the 

scenario  to  iaodi:& 


exits  scenario  choice  Eystem 
&  re-displiys  this  menu 
diame  lists  the  composition 
of  tbe  'napie*  scenario 


MAKEUP— STAGE  1 


He  is  asked  if  he  wants  to  know  the  composition  by  indivi- 
dued  data  base  relation^  or  by  family/group.  He  chooses  the 
letter  and  ALIAS  prints  out  a  list  of  groups  similar  to  the  one 
he  was  asked  about  during  scenario  creation,  along  with  the  name 
of  the  scenario  the  data  is  currently  coming  from  (these  names 
are  the  values  the  SCENARIO  field  takes  on  in  the  DB  relations  in 
the  respective  groups) .  In  this  case,  a  value  of  FIXIT  indicates 
that  the  data  is  indirect-access,  and  DEMO  that  it  is  direct 
access.  The  .MISCJ  data  indeed  is  of  the  indirect  access  variety 
for  scenario  DEMO. 

The  scenario  system  prompts  again  for  a  command  or  the  name 
of  the  scenario  to  modify.  JOHN,  now  ready,  responds  with  the 
name. 


In  the  next  freune  (stage  2)  JOHN'S  fundamental  choice  is 
the  level  at  which  the  change  will  be  made.  To  change  the  status 
of  an  individual  relation's  data  the  "CR”  command  should  be 
given;  to  change  the  status  of  a  whole  group/family  the  "CS"  com¬ 
mand  is  required.  It  is  generally  wise  to  make  changes  on  an 
entire-group  basis,  so  JOHN  chooses  CS. 


Do  you  want  the  oonpoeltion  ty  relation  (ncMy  femily)?  n 


SCEMARIGS  OdmUBOTINS  TO  SCENARIO  DEMO 

BOiAITIOM  FAMILY  USES  DATA  EROM 

CDRR7  PIXIT 

DESCJ  EEHO 

HISTJ  FIXIT 

HESCJ  Fixrr 

PASAMS  DEMO 

PROU  DEMO 

YARDS  Fixrr 

NAME  Of  scenario  to  modify,  or  QOMMAND:  DEMO 


/////////////////////////////////////////////////////////////////// 


***  MODIFYING  IWEDP  OF  SCENARIO  DEMO  *** 

Scenario  modification  options  includes 

?  presides  help  ^  exits  scenario  choice  Eystem 

CS  change  cemposition  ty  family  LS  list  cemposition  ty  family 

CR  change  ocn^sition  ty  file  LP  list  composition  ty  file 

&  re-displeys  this  menu 


In  stage  three  JOHN  specifies  the  changes  he  wants  made. 
This  is  done  using  an  equation-like  syntax,  as  the  prcxnpt  indi¬ 
cates.  In  this  particular  case  what  JOHN  does  seems  a  little 
redundant:  he  asks  that  the  new_ source. scenario  for  the  .NISCJ 
group's  data  be  FIXIT,  but  the  source  scenario  was  already  FIXITI 
His  goal  is  to  keep  using  the  FIXIT  data,  but  directly  rather 
than  indirectly.  Thus  he  really  just  wants  to  answer  "Yes"  to 
the  "Do  you  want  a  data  copy  made"  question,  which  is  identical 
in  meaning  to  the  "Will  you  want  to  change  the  data  in  that 
group?"  question  asked  during  scenario  creation. 

A  pause  follows  while  the  data  copy  is  done;  then  the 
"Change  made."  message  appears.  Since  this  is  the  only  thing 
JOHN  wanted  to  do,  he  "pops"  using  the  "*"  command,  pops  again 
back  into  the  Command  System  SCEN  menu,  and  jumps  to  the  TOP  menu 
(with  /) . 
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Soenaud.0  modification  options  include: 

?  provides  help  I  exits  scenario  choice  eystem 

@  lists  current  scenarios  i  @nane  lists  composition  of  NAME 

&  re-dispLa^s  this  menu  I  FAMIL^NDr  SOURCE  specifies  change 


CBAMSE  SCSIARIO  MKEUP— SIXGE  3 
IB.FAMIL!^NBLSODRa^SCZNAR10,  or  OOMAMD:  mSGJ-FIlIT 

Do  you  want  a  oo£y  of  that  data  made  (no^only  read  it)  ?  T 

Change  made. 

IB.FAMIL^NBC90DBC^SCENAR10,  or  OOMAND: 

OOMAMD: 


/////////////////////////////////////////////////////////////////// 


Menu  is  SCEM  *  ALIAS  OOMWID  S)S1£M  *  Scenario  is  DEMO 


_  SCENARIO  SYSTEM  MENU 

1.  CHOOSE  A  DIFEERQIT  SCENARIO  ID  WORK  WIIH 

2.  CREATE  A  NEW  SCENARIO 

3.  DELETE  ODRRBflLY  EXISTINS  SCENARIOS 

4.  LIST  CURRENTLY  EXISTINS  SCENARIOS 

5.  SEND  LIST  OF  EXISTINS  SCENARHS  TO  LINE  HUNTER 

6.  MODIFY  THE  fAKEUP  OF  AN  EXISTINS  SCENARIO 


JOHN  asks  for  the  DBU  again.  Users  running  at  a  terminal 
will  notice  that  its  response  is  almost  immediate,  in  comparison 
to  the  long  startup  delay  the  first  time  it  was  requested. 

Screen  MASTER  comes  up  rather  than  the  CLASS. CHARS  screen 
JOHN  was  running.  He  can't  jump  right  back  to  that  screen 
because  he  might  have  changed  the  scenario  he  was  using  while  out 
of  the  DBUr  and  DBU  screens  set  up  scenario  security  during  their 
set-up  phase. 

Wanting  to  return  to  the  CLASS. CHARS  screen,  JOHN  remembers 
its  name  since  he  was  just  using  it.  When  you  know  the  name  of 
the  screen  you  want  to  use  in  the  DBU,  you  can  jump  to  it 
directly  by  giving  the  "ascreen.name*  command  instead  of  working 
your  way  down  the  chain  of  menus.  JOHN  has  set  up  and  executed 
the  appropriate  command  in  the  MASTER  screen  in  the  bottom  frame 
opposite. 


Mmu  is  TOP 


*  ILIfS  OOlteilD  sxsm  *  Scenario  is  DEMO 


IDP  LEVEL  K.IAS  CXXWWD  HEX« 
ODfflDNIZE  USER  El^lRCNMEllT 
CAEI.  NON-iSilAS  FICCESSQRS 
DATA  BASE  UHATINS  S»S1£M 
MANJtfi  ASSBaNMQlT  EDITGR 
EORCS  LEm.  REPORT  GOIBUODR 
SCQIARID  CBOICE/MIKEUP  SYSTEM 


OOMAND:  3 
Back  in  IBU  now. 


/////////////////////////////////////////////////////////////////// 


SCREOl  IS:  MASTER 


?  tor  help 


SCENARIO  IS:  EEMO 


ALIAS  OAXA  BASE  UPDATE  SYSTEM 

■choose  a  screen  to  use  ty  nunber  or 

OOmAND:  «CLAS£LCBARS 


1.  SHIP  CLASSES 

2.  SBIP  J(B  TZFES 

3.  SBIP  JCB  SGBELULES 

4.  SBIP  YARDS 

5.  SBIP  OEACriVATICNS 

6.  DATR  DICTICNARY  UPDKTIIC  SYSTEM 


■NAME  junps 


""  ■III  III  1 11  I  1  No  data  mey  be  changed  hero»"  ■■  »ii.  nmi 

Please  pLace  a  cannand  or  option  nunlDer  after  OOHAMID  and  press  RETURN 


Getting  screen, 


JOHN  has  to  repeat  the  K-S  (dear-search  sequence)  to  get 
the  DDG-2  record  he  was  looking  at.  Notice  that  the 
privilege  line  at  the  bottom  of  the  screen  now  says  that  JOHN  has 
the  full  list  of  data  change  privileges,  now  that  he  is  working 
with  his  "own"  copy  of  class  characteristics  data. 
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IS:  aiASS.CSABS 


?  for  help 


Q£iss  Neme: 
Name  for  R^rts: 


DAilA  BASE  UPDATE  SYSTEM 
■■Ship  Qass  Characteristics ' 


■NAME  3unps 


OOMAND:  K 


CWner :  USN 


SHIP  SIZE 


SIP  LIFE 


Length  Beam  Hei^t  Draft  Displacement  Standard  Service  Tame 
Waterline:  After  Delivery: 

Overall:  i*'  Units:  MCNTHS 

At  Launch:  Source 

Light :  Data  Date 

Full  Load:  Entry  Date  4/19/1984 

Entry  By  MAI® 

=Your  privileges  in  this  screen  eure:  inspect^  ad&f  modify^  update^  delet^“ 
Place  a  comnand  after  COMMAND  and  press  RETURN 

/////////////////////////////////////////////////////////////////// 


SO^EEN  IS:  CLASS  CHARS 


?  for  help 


latest  data 


SCENARIO  IS:  EEMO 


iOiIAS  DATA  BASE  UPDATE  SYSTEM 
»Ship  Qass  Characteristics"^ 

QOMAND:  S 


■NAHC  junp 


Qass  Name:  DOG 


CWner: 


Name  for  Reports: 


SHIP  SIZE 


SHIP  LIFE 


Length  Beam  Hei^t  Draft  Displaoemait  Standard  Service  Time 
waterline:  After  Delivery: 

Overall:  in  Time  Units: 

At  Lamch:  i^nta  Source 

Light:  Data  Date 

Pull  Load:  Entry  Date 

Entry  By 

Your  privileges  in  this  screen  are:  inspect,  add,  modify,  update,  deletCF 
Place  a  ocninand  eifter  OCMAND  and  press  RETUIN 


He  sets  up  his  modification  again  (45  year  life  rather  than 
30) ,  and  this  time  decides  to  change  the  data  date  as  well. 
Changing  the  data  date  makes  it  necessary  for  him  to  use  the  U 
(update)  command  rather  than  the  M  (modify)  command  to  save  his 
change  into  the  data  base.  Instead  of  just  writing  over  the  old 
record^  Update  adds  a  record  with  JOHN’S  changes  to  the  appropri¬ 
ate  file(s)»  preserving  the  old  record  in  case  he  wants  to  get 
back  to  it.  Updating  is  the  most  appropriate  act  in  this  case 
since  JOHN'S  change  is  really  temporary  in  nature. 

In  the  screen  showing  in  the  bottom  frame,  JOHN  has  already 
brought  up  the  description  for  DDG-37  and  done  an  Update  (notice 
the  service  life,  entry  date,  and  entry  by  field  values.  He  is 
preparing  to  "rewind"  back  to  the  start  of  the  file  using  the  "B" 
(back  to  the  beginning)  command  so  that  he  can  look  and  verify 
that  his  changes  were  made. 


?  IOC  help 


DAT^ 


SCQIARIO  IS:  DEMO 


fLUS  DATA  BASE  UPDATE  SYSIEM 
■■Ship  Qass  Qiaracteristico"' 


QOmAND:  D 


■NAME  jimps 


Qass  Name: 
Name  for  Reports: 


CDG-2 


SIP  SIZE 


CWner: 


SIP  LIFE 


Length  Beam  Height  Draft  Disflacement  Standard  Service  Time 
Waterline:  0  0  After  Delivery:  45 

Overall:  0  0  in  Time  Units:  CALYR 

At  Launch:  0  0  0  Data  Source  DIAGIIIH) 

Light:  0  0  0  Data  Date  10/15/1984 

Full  Load:  0  0  0  Entry  Date  3/28/1984 

Entry  By  MARK 

■■‘■Your  privileges  in  this  screen  are:  inspect,  add,  modify,  uixiate,  deIeteF« 
RLaoe  a  oonmand  after  OOHMAND  and  press  REIUfN 

Want  ocmm^s  associated  with  dd  record  brou^t  forward?  (Y)  :N 

/////////////////////////////////////////////////////////////////// 


SCREEN  IS:  CLASS^CHARS 


?  for  help 


LATEST  CATA 


SCENARIO  IS:  DEMO 


ALIAS  DATA  BASE  UPDAIE  SYSIXM 
«Ship  Qass  Characteristic^^ 


■NAME  junps 


ODMIAND:  B 


Qass  Neme:  IXX3-37 


(Vner :  USN 


Nane  for  Reports: 


SIP  SIZE 


SIP  LIEE 


Length  Beam  Height  Draft  Displacenent 


Length  Beam  Height  Draft  Displacenent  Standard  Service  Time 
Waterline:  0  0  After  Delivery:  45 

Overall:  0  0  in  Time  Units:  CALYR 

At  Launch:  0  0  0  Data  Source  CPPP 

Li^ht:  0  0  0  Data  Date  10/W1984 

Full  Ix)ad:  0  0  0  Ehtry  Date  10/16/1984 

Entry  By  JOHNA 

Your  privileges  in  this  screen  are:  inspect,  add,  modify,  update,  delete«^ 
Place  a  ccmmand  after  COMMAND  and  press  REHURN 


3- 


A  few  steps  have  not  been  shown  to  save  space  here.  JOHN 
has  repeated  the  clear-search  sequence  for  DDGs,  which  has 
brought  up  the  description  for  DDG“2,  Note  that  it  is  JOHN  s 

updated  description - the  change  really  was  made.  He  is  giving 

the  N  (next)  command  to  look  to  make  sure  the  DDG-37  class  was 
changed  as  well.  The  bottom  frame  verifies  that  it  was. 

He  does  another  N  to  see  what  comes  next. 


>TZi 


?  for  help 


Qass  Nane: 
Name  for  Reports: 


iOiIAS  Dm  BASE  UKATE  SYSTEM 
»Ship  Qass  Characteristics^ 


■NAME  jumps 


OXfAND:  H 
0)0-2 


Ctoner:  USN 


SIP  SQE 


SIP  LIEE 


Hei^t  Draft  Displaceoaent 


Length  Beam  Hei^t  Draft  Displacement  Standard  Service  Time 
Waterline:  0  0  After  Delivery:  45 

Overall:  0  0  in  Time  Units:  CALYR 

At  Launch:  0  0  0  Data  Source  IMAGINED 

Li^t:  0  0  0  Data  Date  10/15/1984 

Full  Load:  0  0  0  Ehtry  Date  10/26/1984 

Entry  By  JGBNA 

Your  privileges  in  this  screen  are:  inspect,  add,  modify,  update,  delete— 
Place  a  command  after  QOIWAND  and  press  REIURN 


/////////////////////////////////////////////////////////////////// 


SaiEEN  IS:  (XASS.CHARS 


LATEST  DATA 


SCENARIO  IS:  DEMO 


?  for  hdp 


;^IAS  DATA  BASE  UPDATE  SYSTEM 
»Ship  Qass  Characteristics— 

CDMAMD:  R 


bNAHE  junps 


Qass  Nane: 
Name  for  Reports: 


EDG-37 


SIP  SIZE 


(Vner: 


SIP  LIFE 


Hei^t  Draft  Displacement 


Length  Beam  Hei^t  Draft  Displacement  Standard  Service  Time 
Waterline:  0  0  After  Delivery:  45 

Overall:  0  0  in  Time  Units:  CALYR 

At  Launch:  0  0  0  Data  Source  CSDS 

LiAt:  0  0  0  Data  Date  10/16/1984 

Full  Load:  0  0  0  Bntry  Date  10/26/1984 

Entry  By  johna 

Your  privileges  in  this  screen  are:  inspect,  add,  modify,  i;pdate,  delete— > 
Place  a  command  after  OOfMAND  and  press  REIURN 


Finding  DDG-51  next,  and  knowing  he  has  changed  tte 
description  for  the  relevant  classes  from  ncjodat.histj,  he  asks 
to  leave  the  DBU  again.  Back  in  the  TOP  Command  ^stem  menu 
again,  he  is  ready  for  another  battle  group  report  generator  run 
to  find  out  the  effect  of  his  change. 
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SCSEai  IS:  aASS.CB«SS 


LKEEST  DA33V 


SCENARIO  IS:  DEMO 


?  for  hdp 


ALIAS  DATA  BASE  UPDAIE  SYSTEM 
■Ship  Qass  Qiaracteristic 


■NAME  junpe 


Qeiss  Nane: 
Nane  for  Reports: 


ODWIAND:  Q 
CDG-Sl 


Q^ner:  USN 


SHIP  SIZE 


SHIP  LIFE 


Length  Beam 
Waterline:  0  0 

Overall:  0  0 

At  Launch: 

Li^t: 

Full  Load: 


Hei^t  Draft  Displacement 


Standard  Service  Time 
After  Delivery:  30 
in  Time  Onits:  CALYR 

Data  Source  CSD6 
Data  Date  3/28/1984 
^ry  Date  3/28/1984 
Entry  Ey  MARK 

Your  privileges  in  this  screen  are:  inspect^  add,  modify,  update,  deleteB» 
Place  a  comand  after  OOIO0MD  and  press  RETORN 


0 

0 

0 


0 

0 

0 


0 

0 

0 


/////////////////////////////////////////////////////////////////// 


Menu  is  TOP 


*  M.IAS  OOMMMID  SYSOIM  *  Scenario  is  EEMO 


>  - 

v’ 


JOHN  executes  the  battle  group  report  generator  again  using 
the  sane  format  control  file  (BGPOM86 .PMTPIL) .  He  has  to  give  a 
different  name  for  the  file  that  the  report  will  be  saved  in  than 
last  time,  though,  since  the  first  report  is  already  in  the 
BGOEMO  file.  He  chooses  BGREPT  as  the  repository  for  t±e  second 
try's  output. 

Notice  that  JOHN  did  not  have  to  go  modify  the  parameters 
and  list  of  out-of-force  repair  jobs  again,  as  he  did  the  first 
time.  The  changes  he  made  will  remain  in  effect  (for  the  DEMO 
scenario)  until  he  decides  he  wants  to  change  them  again,  even  if 
he  logs  off.  This  is  one  of  the  most  convenient  features  of 

ALIAS - once  you  get  things  set  up,  you  don't  have  to  worry  about 

them  until  you  want  the  set-up  changed. 

The  battle  group  report  generator  provides  its  usual 
progress  messages  as  it  does  its  work.  JOHN  takes  a  break. 

An  important  thing  to  reflect  on  at  this  point  is  the  fact 
that  JOHN  made  a  mistake  in  setting  up  his  scenario  (he  didn't 
realize  that  he  would  want  to  change  ship  life  data,  and  so 
during  the  DEMO  set-up  made  that  data  indirect-access) ,  and  yet 
was  able  to  recover  from  the  mistake  without  much  trouble.  This 

is  generally  true  in  ALIAS - few  mistakes  are  so  serious  that 

they  cannot  be  undone.  The  best  way  to  use  ALIAS  is  to  concen¬ 
trate  on  the  analytical  content  of  the  decisions  you  make  without 
worrying  too  much  about  getting  everything  right  the  first  time. 
It  ^  important  to  review  all  of  the  relevant  system  control 
values,  like  the  contents  of  parameter  menus,  since  they  will 
affect  your  results,  but  there  is  no  harm  done  by  trying  several 
different  settings. 

Serious  problems  can  result  from  a  loss  of  data  base 
integrity,  but  as  long  as  everyone  uses  the  DBU  for  data  base 
updating  the  chance  of  integri^  loss  is  minimized. 


Menu  is  FLRFIB 


*  ILIhS  COmim  SYSTEM  *  Scenario  is  DEMO 


FGRCE  LEVEL  GEMSIATQR 

1.  EORGB  LEVEL  tEEORI  HHTTULIZKnai  PARAMETERS 

2.  EXECUTE  EOO  REECRT  GENERATOR 

3.  EREEARE  BAilTLE  GROUP  REFC^ 

COMAND:  3 


Starting  up  Battle  Group  Report  Generator.  PLease  stand  ty. 

NAME  OF  OUTEUT  OOMTROL  FILE  (name.group,  or  BGP0MB6.FIITFIL 

The  file  ELREPT  alrea<^  exists  in  your  group. 

The  force  levd  nodules  usually  stores  its  ri^rt  in  that 
file  when  you  request  that  the  report  be  saved  on  disk. 

Since  that  file  is  in  use^  what  file  would  you  like  to  store 

the  report  in?  (name  <■  8  letters,  or  /  to  not  save  report) :  BGREPT 


/////////////////////////////////////////////////////////////////// 


Caning  required  data  base  files... 
Looking  for  ships  in  data  base... 
hooking  for  class  BB-61 
Looking  for  class  OG-16 
hooking  for  class  03-26 
Looking  for  class  OG-47 
hooking  for  class  03N-25 
hooking  for  class  03N-35 
hooking  for  class  a3N-36 
Looking  for  class  QGN-38 
hooking  for  class  03N-9 
hooking  for  class  0^41 
hooking  for  class  cy-59 
Looking  for  class  CV-63 
Looking  for  class  0/’<-67 
Looking  for  class  O/N-65 
Looking  for  class  (VN-68 
Looking  for  class  DD-963 
Looking  for  class  EOG-2 
Looking  for  class  EDG-37 
Looking  for  class  CDS-51 
Looking  for  class  EOG-993 
Looking  for  class  FF-1040 
Looking  for  class  ET-1052 
Looking  for  class  FFS-1 
Looking  for  class  FPQ-7 


The  resulting  battle  group  report  still  shows  mixed 
results.  The  number  of  carrier  battle  groups  available  in  the 
1990* s  has  improved  substantially  with  the  change  in  DDG  service 
life  estimates.  There  is  seemingly  even  a  small  surplus  of  DOGs 
Now  the  constraint  on  battle  group  formation  would  seen  to  be 
cruiser  and  DD  availability.  There  are  still  "excess”  carriers* 
enough  to  reach  the  17  CVBG  goal.  And  there  is  still  the 
puzzling  "excess”  of  carriers  in  the  near  term. 

JOHN  decides  that  the  first  order  of  business  is  to  build 
more  cruisers  and  DO's.  He  is  left  in  the  Force  Level  choice 
menu  when  report  production  finishes*  and  asks  for  a  pop  to  the 
top  menu  from  there. 


DEPLOYABLE  BATTLE  GROUP  PROJECTION  FOR  POM-86 
BASED  ON  SURFACE  COMBATANT  REQUIREMENTS  ONLY 
(ALL  DATA  NOTIONAL) 


CALENDAR  YEAR 

1986 

1987 

1988 

1989 

1990 

1991 

1992 

1993 

1994 

1995 

1996 

1997 

1998 

1999 

BATTLEGROUP 

CARRIER  BG 

9 

9 

9 

9 

9 

10 

11 

13 

14 

15 

15 

13 

13 

13 

SURFACE  AG 

MARINE  AF 

1 

1 

SUPPLY  ESCORT 

1 

1 

1 

1 

1 

3 

1 

1 

5 

5 

5 

CONVOY 

10 

10 

10 

5 

5 

10 

8 

5 

BALANCE 

CARRIER 

4 

4 

4 

5 

5 

5 

3 

2 

2 

1 

1 

4 

4 

4 

BB 

1 

1 

1 

1 

1 

1 

1 

CRUISER 

7 

7 

7 

5 

5 

6 

3 

1 

DDG 

1 

1 

5 

5 

5 

DD 

2 

2 

2 

FFG 

FF 

33 

33 

34 

46 

46 

30 

34 

40 

49 

45 

43 

38 

33 

28 

/////////////////////////////////////////////////////////////////// 

Menu  is  FLRPTG 

*  ALIAS  COMMAND 

SYSTEM  * 

Scenario 

is  DEMO 

FORCE  LEVEL  GENERATOR 

1.  FORCE  LEVEL  REPORT  INITIALIZATION  PARAMETERS 

2.  EXECUTE  FORCE  REPORT  GENERATOR 

3.  PREPARE  BATTLE  GROUP  REPORT 

COMMAND:  / 


3-81 


Meau  is  TOP  *  ALIAS  OOMMMID  SYS1EM  *  Soenailo  is  EEI» 


TOP  LEVOi  ALIAS  OOMMAND  MEMO 

1.  CUSTOMIZE  USER  ER7IRCNMENT 

2.  CAIl.  NGN-ALIAS  EROCESSORS 
3  .  DATA  BASE  UICATItC  SYSTEM 

4.  MAMU/ff.  ASSIGNMENT  EDITOR 

5.  FORCE  LEVEL  REPORT  GENERATOR 

6.  SCENARIO  CHOICE/MAKEDP  SYSTEM 

GOMAND:  4 


/////////////////////////////////////////////////////////////////// 


Menu  is  ASSIGN  *  ALIAS  (SMMAND  SYSTEM  *  Scenario  is  DEMO 


mOfL  AS81GNER  SPEaFICATIGNS 

1.  ASSIGNER  lNlTIM.lZiYnGN  PARAMETERS 

2.  EXECUTE  THE  ASSIGNER 

OOIWAND:  1 

1 


His  motivation  is  to  save  some  time  by  reducing  the  amount 
of  data  both  he  and  the  assignee  will  have  to  process.  He  knows 
that  during  this  assignee  run  he  will  change  assignments  only  at 

a  subset  or  the  yards  involved  in  producing  the  POM - only  at 

those  which  he  will  have  building  CG's  and  DDG's.  He  knows 
already  that  there  will  be  only  four  such  yards;  BIW,  INGALLS, 
TODD  LA,  and  TODD  SEA.  By  "turning  off"  edl  the  other  yards  he 
can  make  the  assignee  load  and  present  assignments  only  for  those 
four.  This  will  take  less  time,  and  he  will  not  have  to  "thumb" 
through  several  pages  of  assignments  on  the  screen. 

To  put  this  into  effect  JOHN  asks  to  see  the  list  of 
CANDIDATE  SHIP  YARDS  in  the  parameter  menu.  The  first  page  of 
the  list  is  displayed  in  the  bottom  frame  opposite.  Notice  that 

the  yards  are  edl  "turned  on" - that  is,  they  all  have  an 

asterisk  next  to  their  name.  JOHN'S  first  act  is  to  turn  them 
all  off  with  the  "N"  (none)  command,  and  then  to  turn  BIW  back  on 
by  giving  its  number  (21).  "Hien  he  asks  for  the  next  page  of  the 
list. 
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Menu  is  A£MHV( 


*  PLIIB  OOMMMID  SYSTEM  *  Scenario  is  EEMO 


HANUi^  ASSIGNER  MODULE  IMITIALIZATICM  PARAMETERS 


1.  TIME  UNIT 

»  FISCYR 

(FISCYR,  CALYR,  QTR,  MONTH,  WEEK,  DAY) 

2.  STARTINS  DATE 

»  10/  V1985 

(MV13D/XYYY) 

3.  ENDING  DATE 

-  9/31/1994 

(MVID/YYYY) 

4.  CMIDIDATE  SHIP  YARDS 

a  LIST 

(AII/LIST) 

5.  CANDIDATE  SHIP  CLASSES 

«  list 

(ALI/LIST) 

6.  CMIDIDATE  JCB  TYPES 

»  LIST 

(ALI/LIST) 

7.  DISELAY  BASIS 

a  AWD 

(APPROP,  AND,  START,  KEEL,  INCH,  EELIV) 

8.  ADJUST  BASIS 

a  START 

(AETROP,  AND,  START,  KEEL,INCH,  DELIV) 

9.  ADJUST  MODE 

a  EROGRAM 

(NONE,  EROGRAM,  OOMELX-GBOUP) 

10.  JCBS  EPOCH  OPTION 

a  PROJ 

(AIL,  CURIV^PROJ,  PROJ) 

11.  ailPCLASS  S(^  ORDER 

a  ALEHABETZC 

(ALEHABEnC,  INEUT  ORDER) 

12.  SIPYARD  SORT  ORDER 

a  J^PHifiETIC 

(ALEHABBTIC,  INEUT  ORDER) 

13.  i^TD  REFRESH 

a  OFF 

(ON,  OFF) 

OOmAND:  4«LIST 


/////////////////////////////////////////////////////////////////// 

Menu  is  CBSYD6  *  ALIAS  OOMMAND  SYSTEM  *  Scenario  is  EEMO 


CS0C6E  TBE  SET  OF  VALID  YARDS  TO  f«HICH  SlIPS  M\Y  BE  ASSIGNED 


1. 

*  A&E  IND 

13. 

* 

BEILING 

2. 

*  AAA  SF 

14. 

* 

BETH  BA 

3. 

*  AAA  SO 

15. 

* 

BETH  KEY 

4. 

*  AEDSOO 

16. 

* 

BETH  NJ 

5. 

*  ALLIED 

17. 

* 

BETH  SF 

6. 

*  AMSHIP  T 

18. 

* 

BETH  SP 

7. 

*  ARCWEL 

19. 

* 

BE7I»EAU 

8. 

*  ATTONSCN 

N) 

O 

. 

* 

BETBB06T 

9. 

*  AHJH  ED 

21. 

* 

BIN 

10. 

*  AVONDALE 

22. 

* 

BIN  PORT 

11. 

*  BAYSHIP 

23. 

* 

BOEINGEL 

12. 

*  BELLH^T 

24. 

* 

BOEINGSE 

GOmAND:  H 
QDniAMD:  21 
OOmAND: 


•  -  -  •  -<  4  ^  • 


Ifenu  is  CHSYDS  *  fLltS  CCMmD  SYSHM  *  Scenario  is  EEMO 


CH0C6E  IHE  SET  OF  Vi^ID  YARDS  TO  WHICH  SHIPS  MAY  BE  ASSIGNED 

25. 

BCLAND 

37. 

GEN  SIP 

26. 

BRASWQIi 

38. 

HIGGINS 

27. 

BROOKE 

39. 

HCBOKEN 

28. 

CHASMNSY 

40. 

BCRiE 

29. 

41. 

HP  NSY 

EEFOE 

42. 

INS^yjiS 

31. 

DETYEHS 

43. 

JACK  ENG 

32. 

DILLINHM 

44. 

JACKSHIF 

33. 

EB  GROT 

45. 

JCNAOHAN 

34. 

EB  QP 

46. 

35. 

47. 

LARSOtBT 

36. 

GDQ  CHAR 

48. 

IB  NSY 

OOIflAND:  42 
aOMfiVND:  + 


/////////////////////////////////////////////////////////////////// 


Menu  is  CBSimS  *  i^IAS  GOHHNID  SYSOXM  *  Scenario  is  EEMO 


CHOOSE  IHE  SET  OF  VALID  YARDS  TO  WHICH  SIPS  fAY  BE  ASSIGNED 

49. 

TinrKHRRn 

61. 

NSPCRTS 

50. 

lARE  NSY 

62. 

NNEWS 

51. 

MARINET 

63. 

NQRF  NSY 

52. 

lARINP&E 

64. 

NQRSIP 

53. 

MARTINAC 

65. 

W  MARIN 

54. 

^ARTINLI 

66. 

NY  NSY 

55. 

MARYSIP 

67. 

NY  SIP 

56. 

MERRrrr 

68. 

PAanc 

57. 

METAL  IH 

69. 

PENNSIP 

58. 

MEIHO 

70. 

PERIH  AN 

59. 

MJNRO  ED 

71. 

PETERSCN 

60. 

NASSGO 

72. 

S  NSY 

QOtfnND: 
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Ulo  MO^OOO  ^Ok  UliU  CJ(0 


CHOGBE  IHE  SET  OF  VALID  YARDS 


TO  WHICH  SHIES  HAY  BE 


73. 

IHIL  N5Y 

83. 

SWMAR  SP 

74. 

PIS^BNSY 

84. 

SWV3ERT 

75. 

FOSEINSY 

85. 

IRGOMA 

76. 

SD  IR&ST 

86. 

TDDD  ALA 

77. 

SER  ENG 

87. 

TODD  LA 

78. 

SF  NSY 

00 

00 

. 

TODD  SEA 

79. 

SF  WELD 

89. 

TODD  SF 

80. 

SODTHPRT 

90. 

unsiDR 

81. 

82. 

SfMAR  SD 

SWMAR  SF 

91. 

WILIR&ST 

GOmAND:  87 
OOftlAND:  88 
OOMAND:  ^ 

Sanding  list  oiVoff  settings... 

/////////////////////////////////////////////////////////////////// 

Menu  is  ASNERH  *  ALIAS  COMMAND  SYS1EM  *  Scenario  is  CEMO 


MAHJAL  ASSBjNER  MODCLE  INITIALIZATICN  PARAMETERS 


1. 

TIME  UNIT 

■  FISCYR 

(FISCYRr  CALYRr  QlRr  MONIH,  WE^r  DAY) 

2. 

STARTINS  DKTE 

»  10/  V1985 

(m/DD/VYYY) 

3. 

ENDING  DATE 

»  9/31/1994 

(m/DD/XYYY) 

4. 

CMIDIDATE  SHIP  YARDS 

s  LIST 

(AII/LIST) 

5. 

CANDIDATE  SHIP  CLASSES 

M  list 

(ALI/LIST) 

6. 

CANDIDATE  JCB  TYPES 

»  LIST 

(ALIAIST) 

7. 

DISELAY  BASIS 

«  AfD 

(APPROPr  A<D,  SQVRT,  KEEL,  UO,  DELIV) 

8. 

ADJUST  BASIS 

a  START 

(APPROP,  AfD,  START,  KEEL,INCH,  DELIV) 

9. 

ADJUST  MODE 

«  PROGRAM 

(NCNE,  PROGRAM,  OOMPLX-GROUP) 

0. 

JCBS  EPOCS  OPTION 

»  PRQJ 

(ALL,  CURR/PRCJ,  PRCJ) 

1. 

SIPCLASS  SORT  ORDER 

-  ALPfuecnc 

(ALPHABETIC,  INPUT  ORDER) 

2. 

SHIPYARD  SCRT  ORDER 

«  iOiEHieEnTC 

(i^PHJeEnC,  INPUT  GRDBl) 

3. 

AUTO  REFRESH 

■  OFF 

(CN,CFP) 

OOmAND: 

Saving  parameter  settings 


Menu  is  ASSIGN 


*  ALIAS  OOMMMID  S^SIEM  *  Scenario  is  DEMO 


MAHJJtfi  ASSIGNER  SKanCMTICNS 

1.  ASSIGNER  INlTIALIZAnOM  BARAMETERS 

2.  EXEOm:  IHE  ASSIGNER 

QOMIAND:  2 

Starting  up  Manual  Ship  Assigner.  Expect  a  one  to  five  minute  dele^. 

Loading  assignnents  for  yard  BIN 

Loading  assi^xnents  for  yard  INGMiLS 

Loading  assignnents  for  yard  IDDD  LA 

Loading  assi9inaits  for  yeurd  TODD  SEA 


Notice  also  that  all  the  assignments  for  these  yards  fit  on 
a  single  page^  making  them  somewhat  easier  to  work  with.  JOHN 
adds  two  more  CG-47's  to  the  BIW  yard  with  two  Modify  commands 
(he  could  have  done  it  with  one^  but  he  hit  the  return  key  by 
accident  in  the  middle  of  doing  the  first  one) .  He  asks  for  a 
refresh  of  the  disple^  (&  command). 
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Bftge  lA  Tjme  in:  FISOTR 


Soenario:  EEMO  *SIP  ASSICNMEMTS* 

Y^rd  Period:!  123456789 
Shipdass  T|86  87  88  89  90  91  92  93  94 
B3W  *01 

1  03-47 

2  CDG-51 

QGAIIiS  *02 

1  BB-61  r 

2  03-47 

3  ODG-Sl 

4  IHD 

TODD  LA  *03 

1  DDG-51 
TODD  SEA  *04 

1  AEDM 

2  0X3-51 


4  9  TOTi^Si 

(?»help)  >  II  1.1 


^ — -I — K— I — I — I 

1112 
Yl  F2  1  2 

-H — I — I — I — I— I — I — I 
1 

2  2  2  2 
FI  2  2  2 
L2  1  1 

-H — H — H - 1 — H — 4— H - 1 1 

Yl  2  2  2 

-H — — H - 1 - 1 - H - 1 - 1 

1  1 
Yl  F2  1 

-♦ — H - 1 - 1 - 1 - 1 - 1 - 1 - 1 

3  7  13  12  9 


Modify  assi^inent  to  yard  BIW 

(Blanks  denote  no  diange;  use  sero  for  assignnent  ddetion) 
Period:!  1  ‘2  3456789 
Shipdass  T!  86  87  88  89  90  91  92  93  94 
1  OG-47  !  1  1  1  2 


2 


(?-help)  >  M  1.1 

Modi^  as8i9ment  to  yard  BIW 

(Blanks  denote  no  diange;  use  zero  for  assignnent  ddetion) 
Period:!  123456789 
Shipdass  T! 86  87  88  89  90  91  92  93  94 
1  OS-47  !  1  2  1  2 


1 


(?»hdp)  >  & 
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Now  he  changes  the  INGALLS  assignments  so  that  the  yard  is 
to  build  two  more  CG-47's  and  three  more  DDG-51's.  He  puts  in 
the  extra  ODG'51's  because  the  "surplus”  of  them  shown  on  the 

last  battle  group  report  is  an  illusion - as  soon  as  there  are 

more  cruisers  and  DD's  available,  additional  DDG's  will  also 
be  needed  to  make  up  battle  groups. 

JOHN  asks  to  add  assignments  in  a  new  ship  class  to  INGALLS 
with  the  "A  2"  command.  These  are  DD-963  assignments,  but  he 
hits  the  return  key  by  mistake  again  before  he  has  the  numbers  to 
be  awarded  in  each  year  typed  in.  The  assigner  issues  a  warning 
saying  he  didn't  make  any  awards  for  the  new  class.  He  asks  for 
a  refresh  to  see  what  the  result  of  the  error  is. 


Scenario:  EEMD 
YiLzd  Period: 

Siipclass  T 
Bin  tOl 

1  00-47 

2  DDG-51 
INSAU.S  «02 

1  BB-61  r 

2  CQ-47 

3  HX3-51 

4  LHD 

IDCD  LA  «Q3 
1  EOQ-Sl 
IDDD  SEA  #04 

1  Afm 

2  EDG-51 


*£BIP  ASS1C91MENTS*  Ihge  lA  Tine  in:  FISCYR 


123456789 
86  87  88  89  90  91  92  93  94 

- 1 — ^ H — H - 1 - 1 — •*—■ « —  I 

12  12  1 
Y1  P2  1  2 


2  2  2  2 
FI  2  2  2 
L2  1  1 
— i — I — H — H — i 

Y1  2  2  2 


Y1  F2  1 
-H — I — I — I 

8  13  12  10 


4  9  TDTALSI  3  8  13  12  10 

(?«hdp)  >  N  2.2 

Modify  assigment  to  yard  IMGALLS 

(Blanks  denote  no  chauige;  use  za:o  for  assignnent  deletion) 
Period:!  123456789 
Shipclass  Tj 86  87  88  89  90  91  92  93  94 
2  00-47  12  2  2  2 


(?«h^p)  >  M  2.3 

Modify  assignnent  to  yeu:d  INGALLS 

(Blanks  denote  no  change;  use  zaro  for  assignnent  deletion) 
Period:!  123456789 
Shipclass  T! 86  87  88  89  90  91  92  93  94 
3  DDG-51  !  FI  2  2  2 


(?»heap)  >  A  2 

Make  new  assignment  for  yard  t  2,  INGALLS 
Period:!  123456789 
Shipclass  T!86  87  88  89  90  91  92  93  94 

bcHMi . 

warning:  you  have  assigned  no  ships  of  this  new  class 
(?»heip)  >  & 
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The  new  class  nane  appears  but  with  0  assignmentsr  as  one 
would  expect.  JOHN  proceeds  to  fix  his  minor  mistake  using  the 
Modify  command,  adding  awards  for  five  DD-963's.  He  gives  more 
DDG's  to  TODD  LA  and  TODD  SEA, 


Scenario:  EEMO  *£HIP  ASSIQlMEins*  Rige  lA  Time  in:  FISCYR 

Y&t6  Period:!  123456789  I 

Shipclass  Ti 86  87  88  89  90  91  92  93  94  !' 

BIW  #011 — I — A — H — I — I — I — I — I — I - 1 

1  CX3-47  112  12  1  I 

2  DDG-Sl  I  Y1  P2  1  2  I 

DBAUjS  #02! — I — H-H — I — I — I — I — I — I - - - !■ 

1  BB-61  rj  1  I 

2  CX3-47  12  2  2  2  2  I 

3  ED-963  I  I 

4  DDG-51  I  FI  3  3  3  I 

5  LHD  I  L2  1  1  I 


TODD  LA  #031— H — I — I — I — I — I — I — I — I - - - 

1  EDG-51  I  Y1  2  2  2 

TODD  SEA  #041 — I — I 1 1 — I — I — I 1 — I - 

1  AEDM  I  1  1 

2  EDG-51  I  Y1  F2  1 

I  — I — H — H — H — + — I - 1 - 1 —  I - 

4  10  TOT2)LSl  3  8  14  13  13 
(?»heip)  >  M  2.3 

Modify  assigsnoit  to  yard  SGALLS 

(Blanks  denote  no  change;  use  ztf o  for  assignnent  ddetion) 
Period:!  123456789 
Shipclass  T! 86  87  88  89  90  91  92  93  94 

3  DD-963  I 


11111 

(?»hrip)  >  M  3.1 

Modify  assigmient  to  yard  TCXS  LA 

(Blanks  denote  no  change;  use  zexo  for  assignment  deletion) 
Period:!  123456789 
Shipclass  T! 86  87  88  89  90  91  92  93  94 
1  DDG-51  !  Y1  2  2  2 


3  3 

(?»help)  >  M  4.2 

Modify  assigranait  to  yard  TOIX)  SEA 

(Blanks  denote  no  change;  use  zero  for  assignment  deletion) 
Period:!  123456789 
Shipclass  T!86  87  88  89  90  91  92  93  94 
2  DDG-51  !  Y1  F2  1 


Y2  3 


(?»hrip)  >  fc 


After  reviewing  his  changes  JOHN  decides  he  is  done.  But 
as  he  looks  at  the  assignments  for  INGALLS,  noticing  the  LHDs,  he 
is  reminded  that  he  forgot  to  check  out  that  missing  lead  ship 
job  description  for  LSD-49 's  that  cropped  up  during  the  last 
assigner  run.  Even  though  there  are  no  LSD-49 's  loaded  during 
this  run,  he  decides  to  go  take  care  of  the  matter  right  away 
before  he  forgets  again. 

You  can  put  the  assigner  on  "hold"  while  you  go  do  other 
things,  much  as  the  DBU  is  left  on  hold  whenever  you  leave  it. 

To  exit  the  assigner  via  a  "hold”  JOHN  gives  the  "H"  command.  He 
is  back  in  the  assigner  choice  menu,  where  he  pops  to  menu  TOP. 


Scenario:  CEMO 
Yard  Period: 

Shipclass  T 

Bm  «01 

1  OG-47 

2  IDG-51 
UGAUiS  *02 

1  BB-61  r 

2  CG-47 

3  DD-963 

4  IDG-51 

5  LHD 


TDCD  LA  *03 1 
1  IDG-51  I 
IDOD  SEA  *041 

1  AFCM  I 

2  IDG-51  I 


*aiIP  ASSIGNMEMTS* 
123456789 
86  87  88  89  90  91  92  93  94 

- 1 — 4— H — H — H — H 1 1 - 

12  12  1 
Y1  F2  1  2 


2  2  2  2  2 
11111 
FI  3  3  3 
L2  1  1 


— I — I — H — I — I 

Y1  2  3  3 


ftige  lA  Time  in:  FISCYR 


1  1 
2  F2  3 


4  10  IDTALSI 
(?«help)  >  H 


9  16  15  17 


/////////////////////////////////////////////////////////////////////// 


Menu  is  ASSIGN 


*  ALIAS  OOMMflND  SYSTEM  *  Scenario  is  EEMO 


MANJAL  ASSISIER  SPECIFICATICNS 

1.  ASSIGNER  INrriALIZATICM  PARAMETERS 

2.  EXECUTE  THE  ASSIQIER 


ODMAND:/ 


IDP  LEVEL  ;^IAS  CDMMAND  MEMJ 

1.  CDSIDMIZE  USEH  El^IPCNHEllT 

2.  CAIL  NON-i^IAS  PROCESSORS 

3 .  DAIA  BASE  UPDATING  SYSTEM 

4.  MANUAL  ASSIGNMENT  EDITCR 

5  .  EORCE  LEVEL  REPORT  GENERATOR 
6.  SCENARIO  CSOICE/MAKEUP  SYSTEM 


COIWAND:  3 


Back  in  the  EBU  now. 

/////////////////////////////////////////////////////////////////////// 


SCREEN  IS:  MASTER  SCENARIO  IS:  CEMO 


?  foe  help  ALIAS  DATA  BASE  UPDATE  SYSTEM  =NAME  jmps 

'  choose  a  screen  to  use  by  nunnber  or  ^tiAMEm . . . . ■' 

CDMIAND:  -NCLSKEILFF 

1.  SHIP  CLASSES 

2.  SHIP  J(S  TYPES 

3 .  ailP  JCB  SCBELULES 

4.  SHIP  YARDS 

5.  fflIP  EEAC7nV«nCNS 

6.  DATA  DICTICNARY  UPDATING  SYSTEM 


I  "  No  data  raey  be  changed  here  ■  '  '  '  »■' 

Please  place  a  connand  or  nunber  after  QOMAfflD  and  press  RETUEN 


SCREEN  IS:  NCSKED.PF 


LATEST 


SCENARIO  IS:  EEMO 


?  cor  h€lp 


ALIAS  DATA  BASE  UPDAIE  SYSIEM 
■"Schedule  Planning  Fac±or^" 


■NAME  jimpe 


OOMAMD: 


LSD-49 


Qass: 

Job  TVpe: 

Yard: 

Ccnmissioning: 
Sequence  lype: 
Construction  Method: 
Custcmer: 

Ccmplexity  group: 
De^s  Added  to 
Service  Life 


■Your  privileges  in  this  screen 
Place  a  ccmnand 


intervals 

App:op-Aifcu:d: 

Award-Start: 

Start-Keel: 

Keel-Launch: 

Launch_Del  ivei^ : 

Del  iv-Ccnmission : 

in  Tine  Units: 

Default  Allard  D^: 

Data  Source 
Data  Date 
Entjy  Date 
Entry  By 

are:  inspect,  add,  modify,  update,  deLet 
after  QDftlAND  and  press  REIUPN 


/////////////////////////////////////////////////////////////////////// 


SCREEN  IS:  NQ.SKED  PF 


?  for  help 


LATEST  DATA 


SCQIARIO  IS:  DEMO 


ALIAS  EATA  BASE  UFDAIIE  SYSIEM 
“Schedule  Planning  Eactor9“ 


>NAME  junps 


job 

COMMMID: 

intervals 

Qass: 

LSD-49 

Approp- Award: 

1 

Job  fype: 

NB^CON 

Award-Start: 

12 

Yard: 

ANY 

Start-Keel : 

8 

Comnissioning: 

1 

Keel-Launch: 

23 

Sequence  fype: 

ORDFGL 

Launch_DeI  ivexy : 

24 

Construction  Method: 

NODULZ 

Del  iv-Ccnmission: 

1 

Customer: 

USN 

in  Time  Units: 

MCNIHS 

Complexity  groip: 
Deys  Added  to 

0 

Default  Afard  Day: 

11/01 

Service  Life 

Data  Source  908 

Data  Date  8/01/1984 
Entry  Date  8/0 V 1984 
Entry  By  CBA 

■"Your  privileges  in  this  screen  are:  inspect,  add,  modify,  update,  delete* 

Place  a  coimand  after  COMMAND  and  press  RE1DRN 
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After  inspecting  the  job  descriptionr  he  decides  that  it  is 
not  appropriate  for  the  LEAD  job  and  makes  a  number  of  changes 
(shown  in  'bold').  Then  he  Adds  ("A"  command)  the  new  record  to 
the  data  base.  Notice  that  the  Entry  Date  and  Entry  By  fields 
reflect  the  current  date  and  JOHN'S  user  name  after  the  Add  is 
complete. 

Having  made  his  changer  JOHN  exits  the  DBU  by  giving  the 
"Q"  command. 


SatBM  IS:  NQ.SKEILPF 
?  for  hdp 


LATEST  DATA 


SCENARIO  IS:  DEMO 


ALIAS  DATA  BASE  UPDATE  SYSTEM  «NANE  junps 

"Schedule  Flaming  Fiactoro  ■"  ■  ■  '  ' 


job 

COMAND:  A 

intervals 

Qass: 

LSD-49 

i^pcop-Ai^ard: 

1 

Job  Type: 

NBfON 

Afard-Start: 

16 

Yard: 

ANY 

Start-Keel: 

10 

Ccnmissicming: 

1 

Keel-Launch: 

24 

Sequence  Type: 

LEAD 

Launch_Uel  ivery : 

26 

Construction  Method: 

MODULE 

Dd  iv-Comnission: 

1 

Customer: 

USN 

in  Time  Units: 

MONTHS 

Ccmplexify  group: 
Days  Added  to 

0 

Default  Award  D^: 

11/01 

Service  Life 

Data  Source  IMAGINED 
Data  Date  10/16/1984 
Entzy  Date  8/0^1984 
Entry  fy  IBA 

»«Your  privileges  in  this  screen  are:  inspect,  add,  modify,  update,  delete^" 

FLaoe  a  ocnmand  cifter  ODMAND  and  press  FElUfN 


/////////////////////////////////////////////////////////////////////// 


SCREEN  IS:  NQ,SKE1LPF  LAIEOT  DATA  SCENARIO  IS:  DEMO 

?  for  help  ALIAS  DATA  BASE  UPEATE  SYSTEM  >NAME  junps 

I  »  ■  ■  "Schedule  FLemning  Eactorp^  rwin-mTTi-i  r ,  rr 


COMAND:  Q 

job 

intervals 

Qass: 

LSD-49 

Approp-Arard: 

1 

Job  Type: 

Na^CCN 

Arard-Start: 

16 

Yard: 

ANY 

Stut-Keel: 

10 

Ccmnissioning: 

1 

Keel-Launch: 

24 

Sequence  fype: 

LEAD 

LJ^us1ch_Del  ivery : 

26 

Construction  Method: 

MODULE 

Del  iv-Commission: 

1 

Custcmer: 

USN 

in  Time  Units: 

MONTHS 

Ccmplexify  group: 
Days  Added  to 

0 

Default  A^ard  Day: 

11/01 

Service  Life 

Data  Source  IMAGINED 
Data  Date  10/16/1984 
Ent^  Date  10/26/1984 

Entry  By  JCHNA 

>"Your  privileges  in  this  screen  are:  inspect,  add,  modify,  update,  delete^" 

FLaoe  a  ocnmand  eifter  QOMAND  and  press  REHJEM 
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Returned  to  the  TOP  menu,  he  moves  again  into  the  assigner 
choice  menu  and  chooses  option  2,  "execute  the  assigner".  Since 
the  assigner  was  left  on  hold,  this  does  not  re-start  it — -JOHN 
is  given  a  message  telling  him  he  is  back  in  the  assigner  and 
then  the  assigner  command  prompt.  He  is  effectively  right  where 
he  was  when  he  decided  to  jump  over  to  the  DBU.  Since  he  was 
finished  in  the  assigner,  he  gives  the  "Q"  command  to  trigger  the 
schedule  creation  and  update  step. 


Moiu  is  1DP 


*  ;^IAS  OOMIMID  SXSIEM  *  Scenario  is  EENO 


1DP  LEm.  COMMAND  MEND 

1.  CUSIDMIZE  USER  EM^IRCNMENT 

2.  CAU.  NON-iOilAS  FSOCESSQBS 

3.  OAT2^  BASE  UFDATINS  SXS1EM 

4.  MAN^  ASSIGNMENT  EDITOR 

5.  FORCE  LEVEL  REPORT  GENERATOR 

6.  SCQiARlO  (BOICZ/IAKEUP  SYSIEH 


GOffAND:  4 


/////////////////////////////////////////////////////////////////////// 


Menu  is  ASSIGN  *  ALIAS  COMMAND  SYSTEM  *  Scenario  is  EEMO 


NANJitfi  ASSIGNEE  SFEaFlCKTICNS 

1.  ASSIGNQl  INITIALIZATIGN  PARAMEIERS 

2.  EXECUTE  1HE  ASSIGNEE 


COtfAND:  2 


YOU  HAVE  RETUINED  TO  AN  ACTIVE  ASSIGNEE  SESSION 
UNDER  SCENARIO  DEMO 

IF  THIS  IS  NOT  YOUR  CURRENT  SCZNARIOr  YOU  NJST  LEAVE 
IHE  ASSIGNEE  WITH  THE  'X}"  COMMAND  ittlD  THEN  RE-RJN  IT. 
Press  REIURi  to  continue: 


(?»hd.p)  >  Q 


The  usual  prompt  and  progress  messages  appear.  If  you  are 
following  along  on  your  ter^nal,  notice  that  schedule  creation 
and  update  for  60  ships  in  four  yards  is  significantly  faster 
than  four  160  ships  in  a  dozen  or  so  yards. 


•Qie  assigner  will  now  update  ship  schedules  for  the  current  scenario 

Only  projected  ship  schedules  will  be  updated,  changes  made 
^ring  this  session  which  imply  changes  to  historical  or  current 
job  s^edules  will  be  ignored. 

If  you  made  NO  CHANGES,  or  if  you  want  your  changes  DISCARDED, 
oonsi^able  time  can  be  saved  by  skipping  this  update.  If  you 
do  skip  it,  ai^  changes  you  have  made  will  be  lost. 

Do  you  want  to  skip  the  update?  H 

Opening  data  base  files  for  update, 
l^jdating  projected  ships  data  base. 

Ipdating  schedules  for  yard  BIW 

Ipdating  schedules  for  yard  INGALLS 

Updating  schedules  for  yard  10DD  LA 

Updating  schedules  for  yard  TODD  SEA 

Updating  hull  numbers  in  schedules. 

l^xiate  complete.  Displey  buffers  purged.  Qosing  CB. 


*  /XilAS  CXXIHAND 


Soenazio  is  EEMO 


MANUi^  ASSliCSlER  SKCIFia^IOMS 

1.  ASSIGNEE  INniALIZmCN  BARAMEISES 

2.  EXECUIE  HIE  ASSIGNEE 

OOMAND:  / 


///////////////////////////////////////////////////////////////^/////// 


Mmu  is  IDP 


*  ^lAS  QOWMflND  SYSTEM  *  Scenario  is  CEMO 


TOP  LEVEL  ALIAS  GOMMAND  MENU 

1.  OJSIDMIZE  USEE  ENVIRCMMENT 

2.  CAIL  NCai-ALIAS  PIOCESSOBS 

3 .  DATA  BASE  UPCATHC  SYSTEM 

4.  MANJAL  ASSISIMENT  EDITCR 

5.  FORCE  LEVEL  REPORT  GOIEEATOR 

6.  SCENARIO  (HOICE/MAREDP  SYSTEM 


OOffAND:  2 
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These  are  useful  programs  which  run  on  the  HP.  JOHN'S 
purpose  now  is  to  examine  the  format  control  file  he  has  used  to 
generate  his  battle  group  reports.  He  must  use  a  text  editor  to 
do  thiSr  so  he  asks  for  the  best  one  (the  Text-Document  Processor 
(TDP) }  by  choosing  menu  option  2.  TDP  comes  up  just  as  it  would 
if  the  "TDP”  command  were  given  in  response  to  an  MPE  prompt. 

JOHN  uses  the  "T"  (Text)  command  to  load  in  the  format 
control  file  (called  BGPOH86.FHTFIL) ,  and  then  asks  for  a  listing 
of  all  the  lines  in  the  file. 

We  will  note  a  few  things  in  passing  about  format  control 
files,  although  a  thorough  description  is  left  for  later  in  this 

manual.  Lines  which  start  with  a  "%"  are  "comment"  lines - they 

are  ignored  by  the  report  generator,  and  thus  may  be  included  as 
documentation  or  for  readability. 

Notice  that  the  title  which  has  appeared  on  the  reports 
appears  on  the  TITLE  lines  in  the  file. 


Menu  is  HPRQGS 


*  a}M»6^  SYSIEH  *  Scenario  is  EEMO 


HP  PRDGRAMS 

1.  EDITOR 

2.  TDP 

3.  GRAEH 

4.  RELATO 

5.  MEUI 

6.  SPOOK 


OOmAND:  2 

TDP/3000  (A. 03 .08)  HP36578  Eaitor  (c)  OOPXRIGHT  Hewlett-I&ckard  Co.  1983 

MONr  OCT  29,  1984,  12:05  AM  (DAY  «303) 

/T  BGPOHB6.FIITFIL 
/L  ALL 


99 

100 

101 


102 

103 


104 

105 

106 

107 

108 
109 


110 

111 

112 

IB 

114 

115 


%  ALIAS  BATILE  GROUP  REIOBT  EOE^MAT/CONTENTS  DEETNITICN  ftt.K 
%  fonnat  title;  start;  type;  function;  bgroup;  mateup;  end 
%  title  line  has  titles  for  report 
%  start  line  indicates  start  of  processing 
%  type  line  indicates  ^ip  classes  making  up  a  type 
%  function  line  lists  types  which  can  perform  a  function,  in 
%  order  of  preference 

%  bgroi^  describes  battle  groups  to  be  made  up 
%  makei^  describes  which  functicsvs  each  battle  groqp  requires 

TITLE  Deplcyahle  Battle  Group  PrcgectiPor  POM-86 
TITLE  Based  on  Surface  CCmbatant  Requiranents  Only 
TTELE  (All  Data  Notional) 

% 

START 

% 

%  type  format  similar  to  force  level  report:  name, label, class  list 


A  battle  group  report  format  control  file  is  basically 
divided  into  four  blocks  or  sections:  TYPE,  FUNCTION,  BGROUP,  and 
MAKEUP.  In  the  TYPE  lines  ship  classes  are  aggregated  into  ship 
types,  each  with  a  single  name  and  a  label  for  use  in  the  BALANCE 
section  of  the  report.  The  FUNCTION  lines  define  functional 
categories  of  ships,  each  having  a  list  of  TYPEs  capable  of 
performing  the  function  (in  descending  order  of  suitability). 

Note  that  in  line  127  it  is  specified  that  BB's  can  substitute 
for  CRUISERS,  for  example. 

The  BGROUP  lines  define  the  battle  groups  which  are  desired 
and  the  priority  and  target  number  of  each.  For  example,  in  line 

135  CVBG' are  given  a  priority  of  1  and  a  target  number  of  15, 

with  the  target  effective  from  a  long  time  ago  to  a  long  time  in 
the  future  (it  is  possible  to  have  to  target  number  change  over 
time) .  The  label  that  will  appear  on  the  output  for  this  group 
is  "CARRIER  BG". 

The  MAKEUP  lines  define  what  ships  are  required  to  make  up 
one  unit  of  a  group,  in  terms  of  numbers  of  FUNCTIONal  cate¬ 
gories.  In  line  142  of  the  file  a  CVBG  is  specified  to  require  a 

carrier,  a  cruiser,  4  DDG’s,  2  DD's,  and  4  frigates. 

In  looking  over  the  file  JOHN  decides  three  things.  Hie 
first  is  that  CRUISERS  and  BBs  should  be  able  to  substitute  for 
DDGs.  On  the  last  report  he  noticed  a  relative  surplus  of 
CRUISERS  in  the  near  term,  which  could  relieve  some  of  the  DUG 
shortage.  Editing  implements  this  decision.  Second,  he  decides 
that  8  DD's  is  too  many  to  require  for  a  Marine  Amphibious  Force, 
and  changes  the  requirement  to  only  4.  The  third  is  that  it  is 
perhaps  not  too  much  of  a  surprise  that  he  did  not  achieve  17 
carrier  battle  groups,  since  the  target  was  only  151  He  uses  TDP 
command  to  change  the  target  to  17. 

He  keeps  the  file  under  a  new  name  (which  leaves  the 
original  version  intact,  unchanged),  BGPOM86B.FMTFIL,  and  exits 
the  editor. 

To  find  out  more  about  using  the  TDP  editor,  see  Hewlett- 
Packard's  documentation  for  their  standard  editor  EDITOR  or  for 
TDP  itself.  There  is  an  introductory  manual  for  EDITOR  that  is 
likely  to  be  particularly  helpful. 


116 

117 

118 

119 

119.1 

120 

121 

122 

123 

124 

125 

126 

127 

128 

129 

130 

131 
B2 
133 


TXPE  CARRIER, C3\RRIER,  CV-41,CV-59,C>-63,CV-67,a^5,CVN-68 
TYPE  BB-61 

TYPE  CRUISER, CRUISER,  aGN-25,OGN-36,OGN-38,CEN-35, 

+  03N-9,0G-16,CG-26,0G-47 

TYPE  DDG,EDG,  EDG-2,EOG-37,EOG-51,I]DG-993 

TYPE  DD,I)D  DD-945,DD-963 

TYPE  ETC, ETC,  FTC-1, FTC-7 

TYPE  FT,ET‘  FT-1037,FT-1040,FT-1052 

% 

%  fmction  format  is  name,  list  of  types  which  can  perform  it 
%  in  order  cf  preference 
FTJNCriClI  CRUISER,  CRUISER,BB 
FUNCTION  CARRIER,  CARRIER 
FUNCTICN  UDG,  DUG 

FUNCTION  ED,  DD 

FUNCTICN  ERIGAOE,  FPG,FP 
% 

%  bgroip  format  is  name,output  label, priority, target  level, 

%  broin  date  this  defn  takes  effect,  end  date  this  defn  effective 
BGROOP  0/BG,CARRIER  BG,  1,15,1/1/1900  ,1/1/2111 
BGRCUP  SAG, SURFACE  AG,  3,  4, 3/3/1900, 1/1/2111 
BGRDUP  map, MARINE  AF,  2,  2,1/3/1900,1/1/2111 
BGROOP  ESC,SOPILY  ESO0RT,4, 10, 1/1/1900, 1/1/2111 
BGROUP  a3N,a0NV0fY,  5,10,1/1/1900,1/1/2111 
% 

%  makeup  format  is  battle  grcH^)  name,  function,  #  reqd,  func,  #reqd 
IftKEOP  CVBG,  CARRIER,l,CHJISER,l,DDG,4,DD,2,ERIGAra:,4 

MAKEUP  SAG,  CROISER,2,DDG,2,ERIGA3E,2 

MAKEUP  MAF,  CFUISER,2,EDG,2,ED,8,ERIGAro,10 

MAKEUP  ESC,  EDG,1,ED,1,FRIGA1!IE,2 

MAKEUP  CON,  DD,1,FRIGATE,4 

% 

STOP 


/M  129 

129  FUNCTION  ECG,  EDG 

Changes:  R,CSOISER,BB 

129  FUNCTIQ}  EDG,  EDG,  CRUISER,  BB 

Changes: 

/M  144 

144  I«tKEUP  mF,  CRUISER,2,EDG,2,ED,8,ERIGA'IE,10 

Changes:  R4 

144  MAKEUP  MAF,  CRUISER,2,DDG,2,ED,4,FRIGA'IE,10 

Changes: 

/M  135 

135  BGROUP  CVBG,CARRIER  BG,  1,15, 1/1/1900 ,1/3/2111 

Changes:  R7 

135  BGROUP  O/BG, CARRIER  BG,  1,17 ,1/1/1900 ,1/1/2111 

Changes: 

/K  BGF0ie6B.FMTFIL 
/E 
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Back  in  the  Conunand  System  again,  JOHN  pops  to  the  TOP  and 
heads  for  the  force  level  report  generators  again. 
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Itenu  is  HPROGS  *  M.IAS  OOMMMJD  SYSTEM  *  Scenario  is  EEMO 

HP  PROGRAMS 

1.  EDrrOR 

2.  TOP 

3.  GRAHI 

4.  RELATE 

5.  MENU 

6.  SPOOK 

OOMAND:  / 


/////////////////////////////////////////////////////////////////////// 


Menu  is  TOP  *  It-IiS  ajMMHID  SISIQI  *  Scenario  is  lEMO 


TOP  LEVEL  -MiIAS  COMMAND  MEND 

1.  CDSTDMIZE  USER  E24VIRCMMEirr 

2.  GAIL  NC»J-M.IAS  PROCESSORS 

3.  DATA  BASE  UPDATINS  SYSTEM 

4.  MANUAL  ASSIGNMENT  EDITGR 

5.  EDRCE  LEVEL  REPORT  GENERATOR 

6.  SCENARIO  CBOICE/MAKEXJP  SYSTEM 


OOfflAND:  5 


He  executes  the  battle  group  report  generator,  giving  it 
the  ncune  o£  the  modified  format  control  file  he  just  created. 
The  usual  progress  messages  result. 
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Menu  is  FLRFD3 


*  fLIfS  COMMAND  SYSTEM  *  Scenario  is  EENO 


FORCE  LEm<  GENEHATDR 

1.  FORCE  LfVEL  ISFORT  INlTIALIZmON  BARAMEIEBS 

2.  EXECUTE  FORCE  REICRT  GENERATOR 

3.  IRERARE  BATILE  GROUP  REPORT 

COffAND:  3 

Starting  up  Battle  Group  Report  Generator.  Please  stemd  ty. 

NAME  OF  OUnUT  CONTROL  FILE  (naine.groupr  or  ")BGPOMB6B.PfRFIL 

The  file  ELREPT  alrea<^  exists  in  your  group. 

The  force  level  modules  usually  stores  its  report  in  that 
fUe  when  you  request  that  the  report  be  saved  on  disk. 

Since  that  file  is  in  use,  what  file  would  you  like  to  store 

the  report  in?  (name  <=  8  letters,  or  /  to  not  save  report) :  B6REPTB 


/////J/////J////////J//J/J//J////////////////////////J/J/////////////// 


Cpening  required  data  base  files... 
Looking  for  ships  in  data  base. . . 
Looking  for  class  BB-^1 
Looking  for  class  CG-16 
Looking  for  class  03-26 
Looking  for  class  OG-47 
Looking  for  class  051^25 
Looking  for  class  05N-35 
Looking  for  class  CGN-36 
Looking  for  class  a3N-38 
Looking  for  class  a3N-9 
Looking  for  cleiss  0^41 
Looking  for  class  0^-59 
Looking  for  class  CV-63 
Looking  for  class 
Looking  for  class  a^N-65 
Looking  for  class  O^N-68 
Looking  for  class  CD-963 
Looking  for  class  DDG-2 
Looking  for  class  EOG-37 
Looking  for  class  DOG-51 
Looking  for  class  COG-993 
Looking  for  class  FF-1040 
Looking  for  class  FF-1052 
Looking  for  class  FEG-1 
Looking  for  class  ETG-7 


The  output  is  beginning  to  look  satisfactory.  Given  JOHH  s 
revised  POM,  17  carrier  battle  groups  will  be  deployable  starting 
in  1997.  The  uniformly  small  number  of  ships  "left  over"  as 
specified  in  the  BALANCE  section  of  the  report  indicates  that 
JOHN'S  final  guesses  concerning  the  numbers  of  additional  ships 
required  were  quite  good. 

It  may  seem  odd  to  you  that  the  report  implies  that  the 
Navy  will  be  unable  to  deploy  significant  numbers  of  Any  of  the 
other  kinds  of  battle  groups  (SAGs,  MAP,  etc.).  Remember  that 
this  report  is  based  on  notional  data  only,  though.  It  is  not 
meant  to  be  realistic  (securi^  would  forbid  publishing  a  real^ 
istic  projection  in  this  unclassified  manual  in  any  case) j  it  is 
meant  only  as  an  illustration  of  the  general  way  in  which  ALIAS 
capabilities  can  be  used. 

An  inspection  of  the  current  and  historical  construction 
schedules  being  used  by  scenario  DEMO  (which  actually  belong  to 
FIXIT,  since  JOHN  is  using  FIXIT' s  schedules  in  these  epochs 
indirectly)  would  show  that  a  significant  number  of  cruisers  and 
destroyers  currently  available  are  not  included.  Mso,  the  names 
of  some  classes  were  omitted  from  the  class  lists  in  the  format 
control  file. 

Now  provisionally  satisfied  with  the  report's  contents, 

JOHN  is  ready  to  get  a  copy  of  the  schedules  produced  by  the 
assigner  for  his  POM  (for  review)  and  an  estimate  of  the  POM' s 
yearly  cost. 

ALIAS  currently  has  no  full-fledged  cost-estimation  module. 
However,  JOHN  knows  it  is  possible  to  use  the  capabilities  of  the 
RELATE  query  language  to  prepare  a  rough  cost  estimate.  He  can 
print  out  the  schedules  using  RELATE  as  well. 

Since  RELATE  must  be  run  using  his  "R"  user  name,  the  next 
step  is  to  leave  ALIAS,  which  he  does. 


DEPLOYABLE  BATTLE  GROUP  PROJECTIFOR  POM-86 
BASED  ON  SURFACE  COMBATANT  REQUIREMENTS  ONLY 
(ALL  DATA  NOTIONAL) 


CALENDAR  YEAR 

1986 

1987 

1988 

1989 

1990 

1991 

1992 

1993 

1994 

1995  1996 

1997 

1998 

1999 

BATTLEGROUP 

CARRIER  BG 

10 

10 

10 

11 

11 

11 

12 

13 

16 

16  16 

17 

17 

17 

SURFACE  AG 
MARINE  AF 

1 

1 

1  1 

SUPPLY  ESCORT 

3 

3 

4 

2 

1 

2 

2 

2 

2 

CONVOY 

8 

8 

7 

10 

10 

9 

10 

6 

2 

BALANCE 

CARRIER 

3 

3 

3 

3 

3 

4 

2 

2 

BB 

1  1 

CRUISER 

DDG 

DD 

FFG 

1 

4  4 

FF 

33 

33 

34 

28 

28 

26 

22 

26 

35 

33  31 

26 

21 

16 

/////////////////////////////////////////////////////////////////////// 

Menu  is  FLRFTG 

*  ALIAS  COMMAND 

SYSTEM  * 

Scenario 

is  DEMO 

FORCE  LEVEL  GENERATOR 

1.  FORCE  LEVEL  REPORT  INITIALIZATION  PARAMETERS 

2.  EXECUTE  FORCE  REPORT  GENERATOR 

3.  PREPARE  BATTLE  GROUP  REPORT 

COMMAND:  Q 


Sure  you  want  to  terminate  your  ALIAS  seas ion?  T 
END  OF  PROGRAM 
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:HKI.0  JGB1IR.SBA90 

ENTER  USER  PASSWORD: 

HP3000  /  MFE  17  C.HL.A2.  SAT,  OCT  20,  1984  ,  2:40  PM 
********************************************************** 

WEEKLY  BACK  UP  OF  FILES  IS  NCW  TAKDG  8-  2400  FEET  REELS 
OF  TAPE  AND  LASTING  MCRE  THAN  2  X/2  HOURS.  IT  IS  IMPERATIVE 
IHAT  USERS  OF  IHE  SYSIEM  PURGE  OLD  FILES  CM  A  REGULAR  BASIS. 

************************************************************ 


Bulletin: 

****************************************************************** 
****************************************************************** 
*****************  IX)  NOT  LEAVE  YOUR  TERMINAL  ********************* 
*****************  UNATTENDED  ********************* 

*****************  SIGN  OFF  1111  ********************* 

****************************************************************** 

****************************************************************** 


END  OF  PROGRAM 


Once  in  RELATE,  JOHN  turns  first  to  preparation  of  the 
schedule  printout.  He  opens  the  ncjodat.proj j  file,  which  holds 
the  projected  schedules  for  all  scenarios.  'Hien  he  asks  for  a 
list  of  the  indexes  which  exist  on  the  file- — basically,  these 
are  his  choices  for  the  sort  order  in  which  the  schedules  will 
print  out.  He  chooses  the  first  one  (via  the  SET  INDEX  1)  command 
so  that  the  schedules  will  be  printed  by  yard  and  class,  the  same 
sorting  he  is  used  to  seeing  on  an  assignor  page. 


sBBJOB 

Gcmnent  MAKE  SUBE  HI2934A  IS  TURfED  ON  BEFORE  Hunting, 
Ccnment  OlHEEWISE  YOU'LL  LOSE  SPOOLER  CNMERSHIP. 

FILE  rdbecat.  pub.  ^3«cdbecat.  pub.  relate 

FILE  rdbtielp.  pub.  ^s^rdbheap.  pub.  relate 

FILE  grecat.pub.^9*  grecat. pub.  relate 

FILE  plotter  ;dev»50 

PILE  rdblist;dev*58;OCtl 

BUN  rdate.pub.  relate;lib>7;inaxdatc^3l000 

RELAIE/SOOO  V4.40A  MON,  OCT  29,  1984,  12:27  AM  (C)  C31I 

DOPOI  FILE  NCJODAT.PIiaTJ;lfOD&>SHASa) 

2)£BON  INDEXES 

FILE  NAME  »N070DAT.  PR07J.  SEA90 

TMTRv  1  by  scenario,  yard,  class,  ncjcbt,  hull,  OOMNDM 
KEY  LENSIB  (IN  WORDS) :  23 
DIS'nUBUnCN  *.  159 , 13  ,4  ,2,1,1 

NODE  SIZE  (IN  WORDS)  :  1 
KEYS  PER  BLOCK  :  22 

LEVELS  IN  1SEE  :  2 

KJE6ER  OF  USED  NODES  :  20 
SIDRAGE  UTILIZATICN  :  78% 

INDEX  2  BY  SCENARIO,  CLASS,  HULL,  aDMNUM;UNARy 


KEY  LENSIB  (IN  WORDS)  : 

16 

DISTRIBUTION  : 

159,6,1,1 

NODE  SIZE  (IN  WORDS)  : 

1 

KEYS  PER  BLOCK  : 

30 

levels  in  tree  : 

2 

NU^BER  OF  USED  NODES  : 

16 

STORAGE  UTILIZATION  : 

68% 

index  3  BY  SCENARIO,  OiASS,  DELIVERY 

KEY  LENSTB  (IN  WORDS) : 

16 

DISTRIBUTION  : 

159,6,1 

NODE  SIZE  (IN  WORDS)  : 

1 

KEYS  PER  BLOCK  : 

30 

levels  in  tree  : 

2 

KJtBER  OF  USED  NODES  : 

14 

STORAGE  UTILIZATION  : 

77% 

3)  SET  INDEX  1 

INDEX  «1  IS  NOW  IHE  CURRENT  INDEX. 
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JOHN  then  wants  to  know  what  fields  are  in  the  file.  He 
gives  the  SHOW  command  and  RELATE  lists  them.  He  picks  out  the 
fields  he  is  interested  in  seeing  for  each  schedule  and  puts  them 
in  a  PRINT  command.  Since  he  is  mainly  interested  in  dates^  he 
asks  for  only  the  fields  required  to  identify  each  ship-job  and 
for  the  milestone  date  fields  (omitting  the  commission  mile¬ 
stone).  Notice  that  the  first  word  of  the  command  reads  PR:S:P. 
■PR"  is  shorthand  for  "PRINT".  The  ":S"  tells  RELATE  to  print 
the  fields  in  the  same  column  order  as  he  has  them  named  in  the 
PR  command.  The  ":P"  tells  it  to  do  the  print  on  the  SEA  90  dot 
matrix  printer  instead  of  on  his  terminal.  Thus  he  will  have 
hard  copy  to  take  back  to  his  desk. 

The  output  is  shown  in  Figure  3-1.  Notice  that  JOHN'S  run 
of  the  assignor  for  only  four  yards  did  not  destroy  the  schedules 
for  all  other  yards — -they  were  ignored  or  bypassed  by  the  as¬ 
signor  during  all  phases  of  its  operation.  Notice  also  that  some 
of  the  schedules  have  blanks  for  some  dates.  Did  the  assignor 
make  an  error?  No,  those  schedules  are  for  fiscal  1985  ships, 
and  the  assignor  runs  were  for  fiscal  1986  and  beyond.  Those 
schedules  were  therefore  untouched  by  edl  the  assignor  runs;  the 
blank  dates  were  inherited  from  FIXIT.  Notice  that  all  hull 
numbers  are  ordered  by  delivery  by  the  assignor  (independent  of 
yard).  Notice  how  the  assignor  spread  the  start  dates  of  ships 
within  a  class  and  yard  relatively  evenly  (for  schedules  it  gen¬ 
erated) .  Take  the  three  LSD-41* s  awarded  to  Avondale  in  fiscal 
1986  and  1987.  Their  start  dates  are  about  8  months  apart  (3 
ships  started  over  a  24  month  period»8  month  intervals) ,  even 
though  two  of  them  are  awarded  on  the  same  day. 


4)  SHOT 
FILE  NAME 


»NCJ(XAT.  I^J.  SEA90 


T 


NAME 

Y  PRINT 
P  LEN 

INT 

SIZE 

SCENARIO 

A 

12 

12B 

OASS 

A 

10 

lOB 

HULL 

I 

4 

IW 

QOITKJN 

I 

6 

IW 

YARD 

A 

8 

8B 

NCJOBT 

A 

6 

6B 

JSTYP 

A 

6 

6B 

GDSIDMER 

A 

8 

8B 

SIPNAME 

A 

30 

30B 

CMEIHD 

A 

6 

6B 

AFPRDP 

D 

10 

2W 

AWARD 

D 

10 

2W 

START 

D 

10 

2W 

KEEL 

D 

10 

2W 

U^Ol 

D 

10 

2W 

DELIVERY 

D 

10 

2W 

OOMMISSICM  D 

10 

2W 

DATSACDED 

I 

9 

IW 

AaiORDER 

D 

8 

2W 

DAXADATE 

D 

10 

2W 

DAXASOURCE  A 

10 

lOB 

entklby 

A 

8 

8B 

ENTRX.DATE  D 

10 

2W 

i^TDNOD 

A 

4 

4B 

PROO^ARl 

I 

8 

IW 

PROGVAR2 

I 

8 

IW 

CTURRTITMAP  D 

10 

2W 

miNT  LINE  WI17IH  »  283  CHARACTERS. 


5)PR:S:P  _ 

YARD,  OJ^,  HDLLr  NCJCBT,  JSTSP,  AFPROP,  AWARD,  START,  KEEL,  LAONCa,  DELIVERY 

THE  OUTPUT  HAS  BEEN  PLACED  IN  SPOCL  FILE  #1013 
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Figxire  3-1.  Sample  Schedules 


YSiiD  CLRSS  1«!IL  NCJflBl  JSIVP  RPPIIS?  HJfSD  SIffi!  KEEL  IflUNCH  Dai'JER'!' 


SyOHOSLE  LSO-11 
flUOMOHLE  LSO-*! 
SyilfflflLE  LSD-*! 
flUOHOHLE  LSD-ll 
RUOHDRLE  LSOHl 
RUSHOaE  LSQ-R9 

aMfiimai  r  i  cn.4Q 

ftUSMGHLE  LSO-99 
RUSHOHLE  LS0-« 
R'Jfl.HCflLE  LSS-R9 
RUCKCRLE  LSD*99 
RUOHCPiE  I-SS-12? 
RySMDRLE  I-RO-18? 
RyOHEHLE  I-R3-127 
RyOHORLE  r-RQ-127 
RESHORLE  I-RQ-19? 
R'JSMRLE  I-RO-187 
RyCHOfilE  I-RD-187 
RUS.HSRLE  T-RS*1S7 
R'J2N0RLE  I-R0'187 
RyORORlE  I-R0-!37 
flUOWMLE  t-R0-l87 
RUOHDRLE  r*R0*197 
R'JOHORLE  r-RO-18? 
EI'J  CSH? 

S!'J  CS-R? 

2iy  C8-R? 

3IU  CS-R? 

Siy  CS-R7 
SID  C5-R? 

BID  CS*R7 
BI!i  CS-R? 

BID  OOG-Rl 
SID  506-Sl 
grij  3QS-21 

S!U  DOB-SI 
aril  nnc-ci 

w»W  Jww  vi 

QTij  30£-5i 
fp  COOT  CCCM-'J'^C 

tot#  Vm  w  > 

a  SRQI  SSSH-:^26 
ro  r.PAi  CCOM-77C, 

[3  6PGI  SSEH-?:S 
EBSiiOT  SS8H-725 
[BGPOI  5588-726 
ES  GROI  5SH-2! 

E2  6R0r  SSN-688 
EE  ESDI  SSH-688 


*1  HEUCOM  OSQfOL  Id/Ol/ISSR  11/J0/198R  l/Jl/1986  8/30/1289 

R2  HEUCOM  OSOfOL  10/01/1291  11/20/1281  6/20/1286  1/20/1292 

12  HPJCOH  OROfa  10/01/1295  11/01/1295  11/01/1286  S/fll/1287  1/01/1282  S/01/1220 

11  HEUCOM  OJOfa  10/01/1285  11/01/1295  7/02/129?  1/02/1288  2/02/1282  1/02/1221 

15  HEUCOM  OBOfa  10/01/1286  11/81/1286  2/01/1288  2/01/1288  5/01/1220  2/01/1221 

12  HEUCOM  LERO  10/01/128?  11/01/1297  11/01/1288  7/01/1282  6/91/1221  6/01/1222 

50  HEUCOM  OPOra  10.'01/128?  11/01/1297  5/92/1299  1/02/1229  12/02/1221  12/02/1222 

51  HEUCOM  ORaa  19/91/1988  11/01/1288  11/91/1289  7/01/1220  6/91/1922  6/01/1291 

52  HEUCOM  OROfOL  19/01/1999  11/01/1989  5/02/1220  1/02/1221  12/fl2,'1922  12/02/1221 

52  HEUCOM  OROra  ia'Ql/1282  11/01/1282  11/91/1220  7/91/1221  6/01/1223  6/01/1295 

51  HEUCOM  ORaa  10/01/1999  11/01/1282  5/02/1221  1/02/1222  12/02/1222  12/02/1925 

187  HEUCOM  ORaa  ia'01/123S  11/01/1285  12/91/1985  1/91/1286  11/91/1286  11/01/1997 

198  HEUCOM  OROra  10/01/1981  11/20/1281  1/20/1286  1/29/1299 

182  HEUCOM  OROra  10/01/1285  11/01/1985  6/01/1986  7/01/1296  5/01/198?  5/01/1298 

120  HEUCOM  OROfOL  10/01/1281  11/29/1281  5/29/1286  9/21/1288 

121  aucoH  oRora  10/01/1296 11/01/1286 12/01/1296  i/m/iob?  11/01/128?  11/01/1299 

122  HEUCOM  OROra  10/01/1291  11/20/1291  2/29/1286  12/20/1299 

122  HEUCOM  OROfa  10/01/1286  11/01/1296  6/91/1987  7/01/1287  5/01/1288  5/01/1282 

121  HEUCOM  OROfa  10/01/128?  11/01/129?  12/91/1287  1/01/1988  11/01/1299  11/01/12E2 

125  HEUCOM  ORaa  10/01/1987  ll.'Ol/lBB?  5/21/1289  5/20/1988  1/20/1289  1/29/1920 

126  HEUCOM  OROfOL  10/01/1288  11/01/1288  12/01/1288  1/01/1289  11/91/1982  11/01/1229 

12?  HOICOM  OROfOL  10/01/1288  11/01/1288  6/01/1992  7/01/1289  5/01/1220  5/01/1921 

129  HEUCOM  OROfa  10/01/1282  11/01/1282  12/01/1292  1/01/1220  11/01/1220  11/01/1221 

122  HEUCOM  OROfa  10/01/1299  11/01/1292  5/01/1220  7/01/1220  5/01/1221  5.01/1922 

61  HEUCOM  OROfa  10/01/1281  11/20/1281  9/20/1296  10. 11/1289 

62  .HEUCOM  OROfa  10/01/1985  11/01/1995  1/01/1987  7/01/1287  2/01/1988  5/01/1920 

66  HEUCOM  OROfOL  10/01/1286  11/01/1296  1/01/1289  7/01/1299  2/01/1282  5/01/1221 

62  HEUCOM  OROra  I0,'fll/1296  11/01/1296  2/18/1298  2/18.'12B2  5/19,'!299  1/19/1222 

71  HEUCOM  OROfOL  10/01/1287  11/01/1297  6/06/1292  12/06/1282  2/06/1921  10/06/1222 

71  HEUCOM  OROfa  10/01/1298  11/01/1293  2/21/1220  8/21/1920  10/21/1921  6/21/1222 

76  HEUCOM  OROfa  10/01/1288  11/01/1298  11/02/1220  5/02/1221  7/09/1222  2/02/1221 

72  HEUCOM  OROfOL  10/01/1299  11/01/1292  7/28/1221  1/28/1922  2/28,'1222  11/28.'1221 

52  HEUCOM  YOLERO  10/01/1286  11/01/1296  2/01/1289  11/01/1298  1/01/1220  10/01/1221 

56  HEUCOM  ISIfOL  10/01/1997  11/01/1297  11/01/1288  9/01/1292  10/01/1290  7/01/1292 

62  HEUCOM  OROfOL  10/01/1297  11/01/1297  6/17/1292  2/17/1220  5/17/1221  2/17/1222 

66  HEUCOM  OROra  10/01/1283  ll,'91/1298  1/21/1290  10/21/1220  12/21/122!  9/20.-1292 

72  HEUCOM  OROfOL  10/01/1282  11/01/1282  11/01/1220  8/01/1221  10/01/1922  7/01/1921 

78  HEUCOM  OROfOL  10.'01/1292  ll.'91/1299  !:,'1?/192!  2/17/1922  5/17/1922  2/!:.'199£ 

726  HEUCOM  OROfOL  10/01/1281  ’2/20/1281  1/20.'128S  12/20/1920 

727  HEUCOM  OROfOL  10/01/1995  11/01/1285  12,'91/!995  1/01/1987  2.'01/l22fl  9.'fll/!991 

739  HEUCOM  OROfOL  10/01.'!2S6  ll.'fll.'129S  !2.'01/1986  1/01/1288  2.'01/192!  2.'01.1922 

722  HEUCOM  OROfOL  10/01/1297  11.'01/198?  12/01/1997  1/01/1999  2/01/1222  9/Ql.'!992 

710  HEUCOM  OROfOL  10/01/1293  11/91/1998  12, '01/1983  1/01/1990  2/01/1922  9/01/1991 

711  HEUCOM  OROfOL  10/01/1289  11.-01/1289  12.'01/!982  1/01/1991  2/01/1991  9/01.';595 

21  HPJCOH  LERD  10/01/1288  11.-91/1988  11/01/1988  11/01/1989  5/01/1991  9/01.1992 

757  HPJCOH  OROfOL  10/01/1981  11/20/1981  5/21/1995  12/21/1989 

•'59  HPJCON  OROfOL  10/01/1991  11/20/1981  11/20/1935  5/20/1990 
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Figure  3-1.  Sample  Schedules  (Cont'd) 
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759  HEUCON  OROFOL  10/01/1985  11/01/1985  11/01/1986  1/01/1988  12/01/1989  5/01/1991 

761  HEUCON  OROFOL  10/01/1985  11/01/1985  5/22/1987  7/22/1988  6/22/1990  9/22/1991 

765  HEUCON  OROFOL  10/01/1986  11/01/1986  12/11/1987  2/11/1989  1/11/1991  9/11/1992 

765  NEUCOH  OROFOL  10/01/1986  11/01/1986  7/01/1988  9/01/1989  8/01/1991  11/01/1992 

767  HEUCOH  OROFOL  10/01/1987  11/01/1987  1/20/1989  5/20/1990  2/20/1992  5/20/1995 

769  HEUCOH  OROFOL  10/01/1987  11/01/1987  8/10/1989  10/10/1990  9/10/1992  12/10/1995 

771  HEUCON  OROFOL  10/01/1988  11/01/1988  5/01/1990  5/01/1991  4/01/1995  7/01/1994 

775  HEUCOH  OROFOL  10/01/1989  11/01/1989  11/01/1990  1/01/1992  12/01/1995  5/01/1995 

776  HEUCOH  OROFOL  10/01/1989  11/01/1989  5/25/1991  7/25/1992  6/25/1994  9/25/1995 

1  HEUCON  YOLEfifl  10/51/1987  11/01/1987  11/16/1987  11/22/1987  12/05/1987  12/15/1987 

2  HEUCOH  OROFOL  10/51/1988  11/01/1988  11/16/1988  11/22/1988  12/05/1988  12/15/1988 

5  HEUCOH  OROFOL  10/51/1989  11/01/1989  11/16/1989  11/22/1989  12/05/1989  12/15/1989 

1  HEUCOH  LEflO  10/51/1985  11/01/1985  11/16/1985  11/22/1985  12/05/1985  12/15/1985 

191  COHO  OROFOL  10/01/1987  11/01/1987  12/01/1987  1/01/1988  11/01/1988  11/01/1989 

192  COHO  OROFOL  10/01/1988  11/01/1988  12/01/1988  1/01/1989  11/01/1989  11/01/1990 


1  HEUCOH  LEHO  10/01/1984  4/50/1985  10/50/1985  10/50/1987 

2  HEUCON  ISTFOL  10/01/1984  4/50/1985  2/28/1986  2-'23/1989 

61  9E.9CI  OROFOL  10/01/1986  11/01/1986  12/01/1986  12/01/1986  12/01/1986  8/01/1988 

60  HEUCOH  OROFOL  10/01/1984  11/50/1984  4/50/1986  6/50/1989 

62  HEUCOH  OROFOL  10/01/1984  11/50/1984  10/51/1986  12/50/1989 


64  HEUCOH  OROFOL  10/01/1985  11/01/1985  1/01/1987  7/01/1987  9/01/1988  5/01/1990 

65  HEUCOH  OROFOL  10/01/1985  11/01/1985  7/02/1987  1/02/1988  5/02/1989  11/02/1990 

67  HEUCOH  OROFOL  10/01/1986  11/01/1986  1/01/1988  7/01/1988  9/01/1989  5/01/1991 

68  HPJCOH  OROFOL  10/01/1986  11/01/1986  7/01/1988  1/01/1989  5/01/1990  11/01/1991 

73  HEUCOH  OROFOL  10/01/1987  11/01/1907  1/01/1989  7/01/1989  9/01/1990  5/01/1992 

72  HPJCOH  OROFOL  10/01/1987  11/01/1987  7/02/1989  1/02/1990  5/02/1991  11/02/1992 

75  HEUCOH  OROFOL  10/01/1988  11/01/1988  1/01/1990  7/01/1990  9/01/1991  5/01/1995 

75  HEUCOH  OROFOL  10/01/1988  11/01/1988  7/02/1990  1/02/1991  5/02/1992  11/02/1995 

77  HEUCOH  OROFOL  10/01/1989  11/01/1989  1/01/1991  7/01/1991  9/01/1992  5/01/1994 

78  NEUCOH  OROFOL  10/01/1989  11/01/1989  7/02/1991  1/02/1992  5/02/1995  11/02/1994 

999  HEUCOH  OROFOL  10/01/1985  11/01/1985  5/01/1986  1/01/1987  11/01/1987  5/01/1989 

999  HPJCOH  OROFOL  10/01/1986  U/01/1986  5/01/1987  1/01/1988  11/01/1988  5/01/1990 

1000  HEUCOH  OROFOL  10/01/1987  11/01/1987  5/01/1938  1/01/1999  11/01/1989  5/01/1991 

1001  HEUCOH  OROFOL  10/01/1988  11/01/1988  5/01/1989  1/01/1990  11/01/1990  5/01/1992 

1002  HEUCON  OROFOL  10/01/1989  11/01/1989  5/01/1990  1/01/1991  11/01/1991  5/01/1995 

51  HEUCON  LEBO  10/01/1984  lL'50/1984  4/50/1986  6/50/1989 

52  HEUCOH  ISTFOL  10/01/1986  11/91/1986  11/01/1987  3/01/1988  10/01/1999  7/01/199! 

57  HPJCOH  OROFOL  10/01/1987  U/91/1987  11/01/1988  9/01/1989  10/01/1990  ?/fll.l992 

59  HEUCON  OROFOL  10/01/1987  11/01/198?  5/27/1989  12/27/1989  2/27/1991  11/27/1992 

65  HPJCOH  OROFOL  10/01/1987  11/01/1937  8/20/1989  5/20/1990  7/20/1991  4/20/1995 

67  HPJCOH  OROFOL  10/01/1988  11/01/1988  3/05/1990  12/05/1990  2/05/1992  11/03/1995 

70  HPJCOH  OROFOL  10/01/1988  11/01/1988  •’/02/1990  4/02/1991  5/02/1992  5/02, 1994 

72  HPJCOH  ORD.fOL  10/01/1988  ll.'fll/1998  10/51/1990  7/51/1991  9/50/l»92  6/50/199^ 

’S  HPJCOH  OROFOL  10/01/1989  11/01/1989  5/05/1991  12,'05/199!  2'03/1995  11/05/1994 

79  HPJCOH  OROFOL  10/01/1989  11/01/1989  7,'02/1991  4/02/1992  6/02/1995  5/02/1995 

82  HPJCOH  OROFOL  10/01/1989  11/01/1989  10/51/1991  7/51,-1992  9/50/1995  6/50/1995 

1  HEUCOH  LCRO  10/01/1987  1!/'91/1987  2/01/1989  4/01/1990  6/01/1992  11/01,1995 

2  HPJCOH  OROFOL  !0,'01/!937  11/-01/1987  11/01/1989  1/01/1991  5/01/1995  8/01.1?9« 

3  HPJCOH  OROFOL  10/01/1980  11,01/1983  9.'02/1999  10,'02/!991  12'02/1995  5.'02/!995 

<  HPJCOH  OROFOL  10/01/1989  II, '01/1989  5/fl2,'1991  7/02/1992  9/02, '1994  2, '02, 1996 
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Figure  3-1.  Sample  Schedules  (Cont'd) 


nOI-!  1  NQJCOH  OROrOL  10/01/1394  11/30/1993  12/30/1993  5/30/1997 
tlflRIKT  nOl-l  3  NEUCOH  OROfOL  10/01/1993  11/30/1993  3/30/1995  9/30/1997 
(IflRie  not-l  5  HOffOH  OROfOL  10/01/1995  11/01/1995  11/01/1996  3/01/1997  3/01/1999  5/01/1999 
tlRRIKET  nOI-l  9  NEUCOH  OROrOL  10/01/1995  11/01/1995  7/02/1997  12/02/1997  12/02/1999  1/02/1990 
nORIHET  nOI-l  9  NEUCOH  OROfOL  10/01/1996  11/01/1996  3/01/1999  9/01/1999  9/01/1999  9/01/1990 
tlffillHEI  nSH-1  1  NEUCOH  LE90  10/01/1993  10/15/1993  9/30/1995  9/30/1997 
(IflRIHEI  nSH-l  2  NEUCOH  ISIfOL  10/01/19ffi  11/01/1995  9/01/1996  12/01/1996  11/01/1997  9/01/1999 
ffflRINET  nSH-l  3  NEUCOH  OROfOL  10.111/1995  11/01/1995  10/31/1996  2/29/1997  1/31/1999  10/31/1999 
HfiRIHET  HSH-1  3  HEUCOH  OROfOL  i3/fll/1995  11/01/1995  1/30/1997  5/30/1997  3/30/1999  1/30/1999 
HfiRlNEI  nSH-l  5  NEUCOH  OROfOL  10/01/1995  11/01/1995  5/01/1997  9/01/1997  8/01/1999  5/01/1989 
RSRIHEI  nSH-1  6  NEUCOH  OROfOL  10/01/1986  11/01/1986  8/01/1997  12,'01/1987  11/01/1988  8/01/1989 
nilRIHEI  nSH-l  7  NEUCOH  OROfOL  10/01/1986  11/01/1986  10/31/1997  2/29/1998  1/31/1989  10/31/1989 
IIRRIHET  nSH-1  8  NEUCOH  OROfOL  10/01/1986  11/01/1986  1/30/1988  5/30/1988  3/30/1989  1/30/1990 
HfflllHET  HSH'l  9  HEUCOH  OROfOL  10/01/1986  11/01/1996  3/30/1988  8/30/1989  7/30/1989  3/30/1990 
IIBRIHET  nSH-l  10  NEUCOH  OROfOL  10/01/1997  11/01/1997  9/01/1988  12/01/1988  11/01/1989  8/01/1990 
nflRINET  nSH-l  11  NEUCOH  OROfOL  10/01/1987  11/01/1997  10/31/1989  2/29/1989  1/31/1990  10/31/1990 
IlflRIHEI  nSH-1  12  NEUCOH  OROfOL  10/01/1997  11/01/1987  1/30/1989  5/30/1989  3/30/1990  1/30/1991 
nfiRINEl  nSH-l  13  HEUCOH  OROfOL  10/01/1987  11/01/1987  5/01/1989  9/01/1999  9/01/1990  5/01/1991 
NflRINET  NSH-l  13  HEUCOH  OROfOL  10/01/1989  11/01/1988  8yUl/1989  12/01/1999  11/01/1990  8/01/1991 
NflRINET  NSH-1  15  HEUCOH  OROfOL  10/01/1998  11/01/1998  10/31/1989  2/29/1990  1/31/1991  10/31/1991 
NflRIHET  NSH-l  16  NEUCOH  OROfOL  10/01/1988  11/01/1988  1/30/1990  5/30/1990  3/30/1991  1/30,'1992 
NflRINET  HSH-l  17  NEUCOH  OROfOL  10/01/1988  11/01/1998  5/01/1990  9/01/1990  8/01/1991  S/01/1992 
NflSSCfl  flO-187  193  COHU  OROfOL  10/01/1999  11/01/1989  12/01/1998  1/01/1989  11/01/1989  11/01/1990 
NflSECfl  flO-197  193  CflNU  OROfOL  10/01/1989  U/01/1989  12/01/1989  1/01/1990  11/01/1990  11/01/1991 
NflSSCfl  flfl-197  195  cm  OROfOL  10/01/1989  11/01/1989  8/01/1990  9/01/1990  7/01/1991  7/01/1992 
HflSSCO  flOE  1  HEUCOH  LESO  10/01/1996  11/01/1996  2/01/1989  8/01/1988  7/01/1989  8/01/1990 
HflSSCO  HOE  2  HEUCOH  ISTfOL  10/01/1987  11/01/1987  2/01/1989  8/01/1989  7/01/1990  8/01/1991 
HflSSCO  flOE  3  NEUCOH  OROfOL  10/01/1988  U/01/1998  2.111/1990  9/01/1990  7/01/1991  9/01/1992 
HflSSCO  flOE  3  NEUCOH  OROfOL  10/01/1989  11/01/1989  2/01/1991  8/01/1991  7/01/1992  8/01/1993 
HflSSCO  HR  1  NEUCOH  LLflO  10/01/1989  11/01/1989  2/01/1991  9/01/1991  7/01/1992  8/01/1993 
HflSSCO  LPO-3  16  COHU  OROfOL  10/01/1987  11/01/1987  Z/01/1989  3/01/1990  6/01/1992  11/01/1993 
NflSSCfl  LPO-3  17  COHU  ORWOL  10/01/1998  11/01/1998  2/01/1990  3/01/1991  6/01/1993  11/01/1993 
NflSSCfl  LP9-3  20  COHU  OROfOL  10/01/1989  11/01/1989  2/01/1991  3/01/1992  6/01/1993  11/01/1995 
NflSSCfl  LPO-3  22  COHU  OROfOL  10/01/1989  11/01/1989  11/01/1991  1/01/1993  3/01/1995  9/01/1996 
HNEUS  CUH-68  73  HEUCOH  OROfOL  10/01/1985  11/01/1985  11/01/1986  12/01/1987  3/01/1991  1/01/1993 
NNEUS  CUN-68  75  NEUCOH  OROfOL  10/01/1987  11/01/1987  11/01/1988  12/01/1989  3/01/1993  1/01/1995 
NNEUS  NTS  1  COHU  OROfOL  10/01/1986  11/01/1986  12-'01/1986  1/01/1987  11/01/1987  11/01/1988 
NNRiS  SSN-688  756  HEUCOH  OROfOL  10/01/1983  11/30/1993  3/30/1985  10/30/1989 
NNEUS  SSN-638  760  NEUCOH  OROm  10/01/1985  11/01/1985  11/01/1986  1/01/1988  12/01/1989  3/01/199! 
NHCJS  SSN-6S9  762  NPJCON  OROfOL  10/01/1985  11/01/1985  5/22/1187  7/22/1988  6/22/1990  9/22/1991 
NNPJS  S3N-688  763  HEUCOH  OROfOL  10/01/1986  11/01/1986  12/11/1987  2/11/1989  1/11/1991  3/11/1992 
NNEUS  SSN-6e3  766  HEUCOH  OROfOL  10/01/1986  11/01/1986  7/01/1988  9/01/1989  8/01/1991  11-01/1992 
NN&S  SSN-6c3  768  NEUCOH  OROfOL  10/01/1987  11/01/1987  1/20/1989  3/20/1990  2/20/1992  5/20/1993 
NNEUS  SSN-638  770  NEUCOH  OROfOL  10/01/1987  11/01/1987  8/10/1989  10/10/1990  9/10/1992  12/10/1993 
NNPJS  SSH-638  772  NEUCOH  OROfOL  10/01/1988  11,'01/1988  3/01/1990  5/01/1991  3/01/1993  7/01/1993 
NNEUS  SSN-683  773  NEUCOH  OROfOL  10/01/1989  ll/fll/1989  11/01/1990  1/01/1992  12/01/1993  3/01/1995 
NHTJS  S3N-638  775  NEUCON  OROfOL  10/01/1989  11/01/1989  5/23/1991  7/23/1992  6/23/1993  9/23/1995 
PENNSHIP  LP9-3  18  CGNU  OROfOL  10/01/1988  11/01/1988  2'9!/1990  3/01/1991  6.01/1993  11.01/1993 
PEHSSHIP  LPO-3  19  CONU  OROfOL  10/01/1983  11/01/1988  10/02/1990  12-02/1991  2/02/1993  7/02/1995 
PENNSHIP  LP9-3  21  COHU  OROfOL  10/01/1989  11/01/1989  6.02/1991  8/02/1992  10, '02/1993  3/02/1996 


Figxire  3-1.  Sample  Schedules  (Cont'd) 


PEHNSHIP  I-RCS  1  CflHU  MOrOL  10/01/1981  11/304981  11/30/1981  1/30/1986 
PENNSHIP  I-aCS  2  COHU  OROfOL  10/01/1981  11/30/1981  11/30/1981  S/30/1986 
PENHSHIP  I-flCS  3  COHU  OROfa  10/01/1985  11/01/1985  12/01/1985  1/01/1986  11/01/1986  11/01/1987 
PEllHSHIP  r-ACS  1C0NU  OROTOL  10/01/1985  11/01/1985  5/06/1986  6/06/1986  1/06/1987  1/06/1988 
PENHSHIP  HCS  5  COHU  OROFOL  10/01/1985  11/01/1985  10/09/1986  11/09/1986  9/09/1987  9/09/1988 
PEHHSHIP  l-ACS  6  COHO  OROFOL  10/01/1986  11/01/1986  3/11/1987  1/11/1987  2/11/1988  2/11/1989 
PENHSHIP  r-ACS  7  COHU  OROFOL  10/01/1986  11/01/1986  8/18/1987  9/18/1987  7/18/1988  7/18/1989 
PEHHSHIP  I-ACS  8  COHU  OROFOL  10/01/1-987  11/01/1987  1/21/1988  2/21/1988  12/21/1988  12/21/1989 
PEHHSHIP  r-ACS  9  COHU  OROFOL  10/01/1987  11/01/1987  6/25/1988  7/25/1988  5/25/1989  5/25/1990 
PEHHSHIP  I-AU8  1  COHU  OROFOL  10/01/1981  11/30/1981  12/31/1981  7/31/1985 
PENHSHIP  r-AUS  2  COHU  OROFOL  10/01/1985  11/01/1985  12/01/1985  1/01/1986  11/01/1986  11/01/1987 
PEIERSOH  nOI-l  2  HEUCOH  OROFOL  10/01/1981  11/30/1981  12/30/1981  6/30/1987 
PETERSON  HCn-1  1  HEUCOH  OROFOL  10/01/1981  11/30/1981  5/30/1985  10/30/1987 
PEIERSOH  nCn-1  6  HEUCOH  OROFa  10/01/1985  11/01/1985  11/01/1986  1/01/1987  1/01/1998  5/01/1989 
PETERSON  nOl-1  7  HEUCOH  OROFOL  10/01/1985  11/01/1985  5/02/1987  10/02/1987  10/02/1988  11/02/1989 
TRCOnA  r-A6flS-l  1  HEUCOH  OROFOL  10/01/1981  11/30/1981  5/30/1986  10/30/1987 
TKOHA  I-A60S-1  2  HEUCOH  OROFOL  10/01/1985  11/01/1985  12/01/1985  1/01/1986  11/01/1986  11/01/1997 
IRCHIA  I-A60S-1  3  HEUCOH  OROFOL  10/01/1981  11/30/1981  9/30/1986  2/28/1988 
TACOriA  I-A6flS-l  1  HEUCOH  OROFa  10/01/1985  11/01/1985  1/01/1986  5/01/1986  3/01/1987  3/01/1988 
TMOM  r-A6flS-l  5  HEUCOH  OROFOL  10/01/1981  11/30/1981  1/30/1987  6/30/1988 
IRCOttR  r-A60S-l  6  HEUCOH  QRaa  10/01/1985  11/01/1985  7/31/1986  8/31/1986  6/30/1987  6/30/1988 
TOOO  LA  008-51  51  HEUCOH  YOLERO  10/01/1986  11/01/1986  2/01/1988  11/01/1988  1/01/1990  10/01/1991 
rOOOLA  006-51  58  HEUCOH  OROFOL  10/01/1987  11/01/1987  11/01/1988  8/01/1989  10/01/1990  7/01/1992 
1000  LA  006-51  60  HEUCOH  OROfa  10/01/1987  11/01/1937  1/02/1989  1/02/1990  y02/1991  12/02/1992 
1000  LA  006-51  65  HEUCOH  OROFa  10/01/1988  11/01/1988  11/01/1989  8/01/1990  10/01/1991  7/01/1993 
TODOLR  006-51  68  HEUCOH  OROFOL  10/01/1988  11/01/1988  1/02/1990  1/02/1991  3/02/1992  12/02/1993 
1000  LA  006-51  71  HEUCOH  OROFa  10/01/1988  11/01/1988  9/01/1990  6/01/1991  8/01/1992  5/01/1991 
TOOO  LA  006-51  75  HEUCOH  OROFOL  10/01/1989  11/01/1989  3/03/1991  12/03/1991  2/03/1993  11/03/1991 
1000  LA  006-51  80  HOJCOH  OROFOL  10/01/1989  11/01/1^9  7/02/1991  1/02/1992  6/02/1993  3/02/1995 
TOOO  LA  006-51  83  HEUCOH  OROFOL  10/01/1989  ll/fll/1989  19/31/1991  7/31/1992  9/30/1993  6/30/1995 
1000  SEA  HFOn  1  eCOH  OROFOL  10/01/1987  11/01/1987  12,'01/1987  1/01/1988  11/01/1988  11/01/1999 
TOOO  SEA  AFOtl  2  HEUCOH  OROFOL  10/01/1989  11/01/1989  12/01/1989  1/01/1990  11/01/1990  11/01/1991 
rOOO  SEA  006-51  55  HEUCOH  YOLERO  10/01/1987  11/01/1987  11/01/1988  8/01/1989  10/01/1990  7/01/1992 
TOOO  SEA  006-51  61  HEUCOH  OROFOL  10/01/1987  11/01/1987  1/06/1989  1/06/1990  2/06/1991  12/06/1992 
1000  SEA  006-51  61  HEUCOH  ISTFOL  10/01/1988  11/01/1988  11/01/1989  8/01/1990  10/01/1991  7/01/1993 
TOOO  5EA  006-51  69  HEUCOH  OROFOL  10/01/1988  11/01/1988  1/06/1990  1/06/1991  3/06/1992  12/06/1993 
lOOO  SEA  006-51  71  HEUCOH  OROFOL  10/01/1989  11/01/1989  11/01/1990  8/01/1991  10/01/1992  7/01/1991 
rODO  SEA  006-51  11  HEUCOH  OROFOL  10/01/1989  ll/fll/1989  1/06/1991  1/06/1992  3/06/1993  12/05/1991 
rODO  SEA  006-51  81  HEUCOH  OROFOL  10/01/1989  11/01/1989  9/09/1991  6/09/1992  8/09/1993  5/09/1995 
IflOfl  SEA  fFS-?  61  HEUCOH  OROFOL  10/01/1983  11/30/1981  12/20/1985  9/30/1988 
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Having  printed  the  schedules,  JOHN  is  ready  to  generate  his 
cost  estimate.  He  will  do  this  by  combining  the  data  in  the 
schedule  relation  and  that  in  a  relation  which  specifies  ship 
unit  costs  by  class,  job  type,  and  job  series  type  into  a  single 
relation.  This  relation  will  have  one  record  for  each  ship,  with 
the  ship's  cost  included  in  the  record.  Once  he  has  this  rela¬ 
tion,  he  can  ask  RELATE  to  add  up  the  costs  for  him  in  various 
ways. 


If  you  were  doing  this  exercise  for  the  first  time,  you 
would  need  to  make  up  the  relation  of  unit  costs  and  figure  out 
how  to  ask  RELATE  to  do  what  you  want.  However,  JOHN  has  done  it 
before  and  so  already  has  a  unit  cost  relation.  Also,  he  has 
saved  the  RELATE  commands  which  must  be  given  in  an  editor- type 
file  (called  an  EXECUTE  file  in  this  context). 

JOHN  first  closes  the  ncjodat.proj j  relation  (with  the 
"CLOSE”  command)  because  he  knows  the  execute  file  will  just  open 
it  up  again.  Then  he  executes  the  file,  which  is  stored  in 
costrept. rprocs  ("COST  REPorT.Relate  PROCedure  files").  By 
placing  the  ";SHOW"  option  on  the  EXECUTE  command,  JOHN  has  asked 
RELATE  to  show  him  the  commands  in  the  file  as  it  executes  them. 

First  ncjodat.proj j  is  opened,  then  a  file  called 
unitcst. desc j.  The  latter  contains  the  unit  cost  estimates  which 
JOHN  entered  earlier,  which  are  in  millions  of  dollars,  and  keyed 
by  ship  class,  job  type,  and  job  series  type. 

Then  a  SELECT  is  given  which  "joins"  the  schedule  and  unit 
cost  files  using  the  class,  job  type,  and  series  type  fields,  and 
which  restricts  the  records  returned  from  ncjodat.proj j  to  those 
for  scenario  DEMO.  The  RELATE  manuals  describe  SELECT  and  its 
capabilities  in  detail.  For  now,  think  of  a  join  as  taking  two 
files,  laying  them  on  a  table  side  by  side,  and  glueing  them 
together.  A  retriction  then  throws  out  all  the  lines  which  are 
not  of  interest  (i.e.  which  don't  have  identic^d  key  values 
appearing  in  both  files) . 

The  selection  asks  that  only  three  of  the  many  fields  in 
the  two  files  be  returned  (printable)  for  each  ship  job:  ship 
class,  year  of  appropriation,  and  the  unit  cost  for  the  partic¬ 
ular  job. 

The  result  is  copied  to  a  new  relation  named  TMP.  One 
drawback  of  RELATE  is  that  only  one  selection  at  a  time  may  be 
given.  Since  JOHN  is  going  to  need  to  give  another  select  "on 
top  of"  this  one,  he  must  put  the  results  of  this  one  into  a  file 
so  the  new  select  may  be  given  on  the  data  in  that  file.  The 
file  will  have  one  record  for  each  projected  ship  construction/ 
conversion/  reactivation  job  in  scenario  DEMO,  with  the  name  of 
the  class  the  job  is  being  done  on  and  the  cost  of  the  job. 


6) CL06B 

7) BIBaiTE  G06nBPT.RFROCS;SHCIf 

8) 110^  EROTUCES  A  CRJEE  CXST  PEPGRT  l^INB  UNIT  CX26TS 

9) NCaE  AS  SFEaflED  IN  UNITCST.DESC7 

10)  NCOS 

U)OFEN  FILE  NCJ(XAT.£ncaJ;PA3BaP;I10CB-SBARED 

12) 0PEN  PILE  ONrrCST.DESCJ;PM^;MX)E>*SBARED 

13)  SELECT  CLASS,  YEAI^$YEAR(P.APE«OP)  ,C.CI}ST  WHERE  & 

.lSi)P.(LAS9«C.(LASS  MID  P.NCJCB'&*C.NGJCBT  AND  P.JSTXP»C.JSTXP  &  . 

.2&)AND  P.SCENARIO>''DEMO'' 

14)  copy  TO  TMP 

HIE  '^IMP''  FILE  HAS  BEEN  CREATED  AS  A  FERFANENT  Ra.ATE/3000  FILE. 

187  LINES  COPIED. 

15) 0PEN  PILE  TMP 

16)  SELECT  yEAR,TOTCDSTB$SUM(OOST  BY  YEAR)  UNIQUE  BY  YEAR 

WAHJINS:  TEMPCRARY  INDEX  WILL  BE  CREATED  TO  SATISFY  AGGREGATE  BY  CLAUSE. 

17)  PRINT 

YEAR  TOTCOS 

1983  435 

1984  13050 

1985  18135 

1986  14572 

1987  24415 

1988  19470 

1989  21110 

7  LINES  HUNTED. 

18) Sa.£CT  YEAR, CLASS, TOTOOS^^SUHCCXIST  BY  YEAR,CI.ASS)  UNIQUE  BY  YEAR,CI.ASS 
WAENDG:  TEMPCRARY  INDEX  WILL  BE  CREATED  TO  SATISFY  AGGREGATE  BY  CLAUSE. 

19)  PRINT:? 

THE  OUTEUT  HAS  BEEN  PLACED  IN  SPOCX.  FILE  #1014 

20)  PURGE  PILE  IMP 

THE  "TMP"  FILE  HAS  BEEN  HJRGED. 
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Now  it  is  only  necessary  to  sum  up  the  costs.  The  next 
selection  does  this,  lumping  jobs  together  by  year  of  appro¬ 
priation  and  summing  up  all  the  costs  within  that  year.  The 
'UNIQUE  BY  YEAR”  clause  ensures  that  the  cost  for  each  year  is 
only  printed  once.  JOHN  prints  the  resulting  estimate  to  his 
display. 

He  was  hoping  for  a  fairly  even  distribution  of  costs  over 
the  period,  but  finds  an  uneven  one.  He  will  need  to  revise  his 
schedule  of  awards  somewhat  so  that  extraordinary  appropriations 
are  not  required  in  any  given  year.  To  support  this  revision  he 

will  need  to  know  the  breakdown  of  yearly  costs  in  more  detail - 

he  wants  costs  by  year  and  class. 

All  the  necessary  information  is  already  in  the  TMP  file. 

He  gives  a  new  SELECT  which  is  a  minor  modification  of  the  one 
given  in  the  execute  file  (he  adds  "CLASS"  to  the  aggregate  BY 
clause) ,  and  asks  for  a  print  to  the  SEA  90  dot  matrix  printer. 
•Hie  result  is  shown  in  Figure  3-2.  He  then  purges  the  TMP  file 
since  he  is  done  with  it. 


Figure  3-2.  Sample  Costs  by  Year  and  Class 


YEAR 

CLASS 

TOTCOS 

YEAR 

CLASS 

TOTCOS 

1983 

PPG-7 

435 

1987 

MSH-1 

120 

1984 

CG-47 

3150 

1987 

SSBN-726 

1850 

1984 

DDG-51 

1005 

1987 

SSN-688 

2800 

1984 

LSD-41 

960 

1987 

T-ACS 

120 

1984 

MCM-1 

2980 

1987 

T- AO-187 

200 

1984 

MSH-1 

60 

1988 

AE 

600 

1984 

SSBN-726 

1850 

1988 

AO- 187 

150 

1984 

SSN-688 

2100 

1988 

AOE 

600 

1984 

T-ACS 

120 

1988 

CG-47 

4200 

1984 

T-AG 

265 

1988 

DD-963 

500 

1984 

T-AGOS-1 

240 

1988 

DDG-51 

7  295 

1984 

T- AO-187 

300 

1988 

LHD 

500 

1984 

T-AVB 

20 

1988 

LPD-4 

105 

1985 

AG 

560 

1988 

LSD-49 

1100 

1985 

CG-47 

3150 

1988 

MSH-1 

120 

1985 

CVN-68 

4560 

1988 

SSBN-726 

1850 

1985 

DD-963 

500 

1988 

SSN-21 

850 

1985 

LSD-41 

960 

1988 

SSN-688 

1400 

1985 

MCM-1 

2980 

1988 

T- AO-1 87 

200 

1985 

MSH-1 

13  5 

1989 

AE 

600 

1985 

SSBN-726 

1850 

1989 

AFDM 

200 

1985 

SSt^688 

2800 

1989 

AO-187 

150 

1985 

T-ACS 

180 

1989 

AOE 

600 

1985 

T-AGOS-1 

240 

1989 

AR 

500 

1985 

T- AO-1 87 

200 

1989 

CG-47 

3150 

1985 

T-AVB 

20 

1989 

DD-963 

500 

1986 

AOE 

7  50 

1989 

DDG-51 

8855 

1986 

BB-61 

232 

1989 

LHD 

500 

1986 

CG-47 

4200 

1989 

LPD-4 

105 

1986 

DD-963 

500 

1989 

LSD- 4 9 

1100 

1986 

DDG-51 

2525 

1989 

SSBN-726 

1850 

1986 

LSD-41 

480 

1989 

SSN-688 

2800 

1986 

MCM-1 

745 

1989 

T- AO-1 87 

200 

1986 

MSH-1 

120 

1986 

MTS 

50 

1986 

SSBN-726 

1850 

1986 

SSN-688 

2800 

1986 

T-ACS 

120 

1986 

T- AO-1 87 

200 

1987 

AE 

650 

1987 

AFDM 

200 

1987 

AO- 187 

75 

1987 

AOE 

650 

1987 

CG-47 

3150 

1987 

CVN-68 

4560 

1987 

DD-963 

500 

1987 

DDG-51 

7295 

1987 

LHD 

1060 

1987 

LPD-4 

35 

1987 

LSD-49 

1150 
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JOHN  decides  he  would  also  like  a  printout  of  the  unit 
costs  which  his  estimates  are  based  onr  so  he  does  a  SET  PATH  C 
to  gain  access  to  the  unitcst.descj  file  (which  was  opened  with  a 
path  name  of  "C"),  looks  to  see  what  fields  are  in  it,  and  prints 
its  contents  to  the  dot  matrix  printer  (see  Table  3-3) . 

Finished  with  his  session,  JOHN  leaves  RELATE  and  logs  off 
the  computer. 

We  want  to  emphasize  the  power  and  usefulness  of  the  method 
that  JOHN  just  used  to  get  his  cost  estimate.  The  use  of  "job 
description"  or  "unit  cost"  or  "labor  requirements"  relations  in 
combination  with  the  schedules  in  the  ALIAS  data  base  can  support 
conduct  of  many  analyses  in  addition  to  those  that  ALIAS  already 
supports.  To  see  how  to  undertake  these  analyses,  spend  some 
time  exploring  the  capabilities  of  RELATE,  and  in  particular  the 
use  of  aggregates  in  the  SELECT  command. 


21) SBT  IMS  C 

22) SB0H 

FILE  NAME  «UNnCST.IX;SG7.SEA90 

T 

Y  HUNT  INT 

NAME  P  LEN  SIZE 

(XASS  A  10  lOB 

NCTCBT  A  6  6B 

JSTYP  A  6  6B 

CDST  16  IW 

FRINT  LINE  WIDTH  *  35  CHARACTERS. 

33) PR1NT:P 

THE  OUTEUT  HAS  BEEN  PLACED  IN  SKXX  FILE  *1016 

34) // 


END  OF  PROGRAM 
:BYE 


A  lot  of  things  have  been  introduced  in  this  sample 
session.  Among  them  ace: 

1)  How  to  log  on  to  the  ALIAS  host  computer 

2)  How  to  run  the  ALIAS  Core  and  its  Command  System 

3}  How  to  do  ad  hoc  queries  of  the  ALIAS  data  base,  and  how 
to  combine  these  capabilities  with  Core  capabilities  to 
analyze  ship  acquisition  programs 

4)  What  scenarios  are  and  how  to  create  and  work  with  them 

5)  The  assignee,  which  makes  creation  of  program  schedules 
easy 

6)  The  battle  group  report  generator,  which  lets  you  assess 
the  impact  of  a  program  on  the  force  structure 

7)  The  Data  Base  Updating  system,  which  lets  you  inspect 
and  change  the  data  base 

In  a  more  general  sense,  you  have  seen  most  of  the  epntexts 
which  you  are  likely  to  encounter  when  working  with  ALIAS,  and 
you  have  seen  most  of  ALIAS'  major  capabilities. 

It  m^  seem  at  this  point  that  there  is  a  bewildering  array 
of  things  that  you  have  to  know.  As  a  system  of  building  blocks 
or  tools,  it  is  true  that  ALIAS  offers  you  many  options  and  ways 
of  doing  things.  .  However,  there  is  guidance  for  most  steps  in 
the  form  of  menus,  and  it  is  often  not  necessary  to  know  all  the 
options. 

Hot  shown  during  the  sample  session  is  the  extensive  array 
of  on-line  help  which  ALIAS  makes  available.  You  can  ask  for 
this  help  at  any  time  by  giving  the  "?■  command.  It  is  a  good 
idea  to  give  this  as  your  first  command  whenever  you  are  doing 
something  you  have  never  done  before,  just  to  find  out  what  kinds 
of  help  are  available  in  case  you  get  confused. 

The  most  important  subtle  thing  to  rem^nber  about  ALIAS  is 
that  nearly  everything  uses  the  contents  of  the  data  base  in  some 
way.  You  must  understand  what  data  is  in  a  scenario  when  you 
begin  to  use  it,  and  keep  track  of  the  changes  you  make  to  it  as 
you  go  along.  When  strange  results  appear  for  no  seeming  good 
reason,  think  about  the  data  elements  the  results  are  based  on 
and  what  pattern  or  element  veilues  might  yield  the  results.  This 
is  what  JOHN  did  when  he  got  in  trouble  in  the  sample  session; 
and  notice  that  most  of  the  times  he  got  in  trouble  were  a  result 
of  his  not  being  very  familiar  with  his  starting  point,  the  PIXIT 
scenario. 

The  remaining  Sections  of  this  manual  will  describe  in  more 
detail  how  to  operation  each  of  ALIAS'S  constituent  parts. 
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Figure  3-3.  Sample  Unit  Costs 


$LINE  CLASS  NCJOBT  JSTYP  COST 


1 

AE 

NEWCON 

ORDFOL 

600 

2 

AE 

NEWCON 

YDLEAD 

650 

3 

AFDM 

NEWCON 

ORDFOL 

200 

4 

AG 

NEWCON 

LEAD 

560 

5 

AO- 187 

CONV 

ORDFOL 

75 

6 

AOE 

NEWCON 

ISTFOL 

650 

7 

AOE 

NEWCON 

LEAD 

750 

8 

AOE 

NEWCON 

ORDFOL 

600 

9 

AR 

NEWCON 

LEAD 

500 

10 

BB-61 

REACT 

ORDFOL 

232 

11 

CG-47 

NEWCON 

ORDFOL 

1050 

12 

CVN-68 

NEWCON 

ORDFOL 

4560 

13 

DD-963 

NEWCON 

ORDFOL 

500 

14 

DDG-51 

NEWCON 

ISTFOL 

855 

15 

DDG-51 

NEWCON 

LEAD 

1005 

16 

DDG-51 

NEWCON 

ORDFOL 

805 

17 

DDG-51 

NEWCON 

YDLEAD 

835 

18 

FFG-7 

NEWCON 

ORDFOL 

435 

19 

LHD 

NEWCON 

LEAD 

560 

20 

LHD 

NEWCON 

ORDFOL 

500 

21 

LPD-4 

CONV 

ORDFOL 

35 

22 

LSD- 41 

NEWCON 

ORDFOL 

480 

23 

LSD-49 

NEWCON 

LEAD 

600 

24 

LSD- 49 

NEWCON 

ORDFOL 

550 

25 

MCM-1 

NEWCON 

ORDFOL 

745 

26 

MSH-1 

NEWCON 

ISTFOL 

45 

27 

MSH-1 

NEWCON 

LEAD 

60 

H-1 

NEWCON 

ORDFOL 

30 

ORDFOL 

50 

30 

SSBN-726 

NEWCON 

ORDFOL 

1850 

31 

SSN-21 

NEWCON 

LEAD 

850 

32 

SSN-688 

NEWCON 

ORDFOL 

700 

33 

T-ACS 

CONV 

ORDFOL 

60 

34 

T-AG 

NEWCON 

ISTFOL 

125 

35 

T-AG 

NEWCON 

LEAD 

140 

36 

T-AGOS-1 

NEWCON 

ORDFOL 

80 

37 

T- AO-1 87 

NEWCON 

ORDFOL 

100 

38 

T-AVB 

CONV 

ORDFOL 

20 

38  LINES  PRINTED 


4.0 

The  Command  System  is  the  framework  on  which  ALIAS 
analytical  capabilities  are  hung.  It  shows  you  lists  of  the 
things  which  you  can  do,  accepts  your  choices,  and  ensures  that 
your  wishes  are  carried  out.  It  is  menu-oriented,  meaning  that 
ALIAS  options  are  shown  in  related  groups,  with  only  one  such 
group  being  shown  at  a  time. 

To  use  the  Command  system  you  need  only  know  a  few  commands 
and  conventions,  all  of  which  were  illustrated  during  the  sample 
session.  There  are  several  additional  services  and  advanced 
capabilities  as  well,  which  were  not  shown  in  the  sample.  This 
Section  is  a  complete  guide  to  the  nature  and  use  of  the  Command 
System. 


4.1  EXECUTING  THE  COMMAND  SYSTEM 

Before  you  can  use  the  Command  System  two  things  must  be 
done.  First,  you  must  be  given  an  "A”  user  name  by  an  ALIAS 
system  administrator.  Most  people  in  the  ALIAS  community  have 
two  user  names  which  they  can  use  to  log  onto  the  HP,  e.g. 

"JOHNA"  and  "JOHNR".  The  "A"  name  is  for  running  the  Command 
System  and  all  its  associated  capabilities,  while  the  ”R”  name  is 
for  making  direct  queries  of  the  data  base  using  RELATE.  Secu¬ 
rity  constraints  made  the  2-name  system  necessary. 

The  second  requirement  is  that  the  ALIAS  system  adminis¬ 
trator  set  up  security  such  that  you  will  be  accepted  by  ALIAS, 
i.e. ,  you  must  be  given  privileges.  Three  kinds  of  privileges 
will  typically  be  required:  basic  RELATE  usage  privileges  for 
both  your  user  names.  Command  System  access  privileges,  and  Data 
Base  Updating  system  usage  privileges.  The  administrator  will 
give  you  the  privileges  just  after  establishing  your  user  names, 
so  you  probably  need  not  worry  about  them. 
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Once  you  are  set  up  you  need  only  log  on  under  your  "A" 
name  (sit  down  at  a  terminal,  hit  the  return  key,  and  type  "HELLO 
JOHNA. SEAdO",  using  your  name  instead  of  "JOHNA”) ,  and  give  the 
command  "ALIAS"  in  response  to  MPE's  colon  prompt. 

4.2  THE  NATURE  OF  COMMANDS 

You  control  what  actions  ALIAS  takes  by  giving  commands  to 
the  Command  ^stem.  As  explained  in  Section  2,  there  are  two 
basic  means  of  giving  commands  in  ALIAS  as  a  whole:  line-oriented 
and  f ill-in- the-blank.  The  Command  ^stem  expects  line-oriented 
commands  exclusively. 

Line-oriented  systems  type  out  a  prompt  when  they  are  ready 
to  process  your  next  request;  they  expect  you  to  type  something 
in  response  (right  after  the  prompt,  using  no  arrow  keys,  though 
use  of  the  backspace  key  is  permitted)  and  hit  the  RETURN  key. 

The  Command  System's  prompt  is  "COMMAND;";  when  this  is  the  last 
line  appearing  on  the  display  the  system  is  waiting  to  do  your 
bidding. 

The  responses  you  give  to  the  "COMMAND:"  prompt  will  take 
three  basic  forms:  numbers,  other  characters,  and  settings. 

The  command  system  will  always  present  you  with  a  menu  of 
choices  before  giving  the  prompt;  when  you  type  a  number  in 
response  to  the  prompt  you  are  indicating  that  you  want  to  choose 
that  numbered  option  from  the  menu.  The  system  will  respond  by 

doing  whatever  the  option  implies - perhaps  it  will  execute  a 

module,  or  show  you  a  different  menu,  or  just  change  something's 
status. 

In  addition  to  choosing  from  the  menu  there  are  "house¬ 
keeping"  functions  which  you  can  perform  (generally  from  any 
menu) ,  such  as  ending  your  session.  You  invoke  one  of  these 
functions  by  giving  the  proper  non-numeric  character  ("Q"  in  the 
case  of  ending  the  session) . 
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Settings  change  the  status  of  a  system  control  variable, 
such  as  the  start  date  of  interest  for  a  run  of  a  particular 
module.  Settings  are  typically  multi-character  commands,  in 
which  you  indicate  which  variable  you  want  to  change  and  what  you 
want  its  new  value  to  be.  You  indicate  the  variable  by  its  num¬ 
ber  on  the  menu,  and  its  value  by  typing  the  value  after  an  equal 
sign;  an  example  would  be  "3=10/1/1995". 

4.3  TYPES  OF  COMMAND  SYSTEM  MENU 

The  Command  System  will  present  you  with  four  types  of 
menu.  Each  t^pe  has  a  different  purpose,  and  often  a  somewhat 
different  set  of  commands  which  you  can  give.  The  types  are 
choice,  parameter,  list,  and  help  menus. 

4.3.1  Shoi^^JSssuiS 

Choice  menus  are  action-oriented.  If  you  choose  any  of  the 
numbered  items  which  appear  on  a  choice  menu,  the  system  will 
take  one  of  two  actions;  it  will  show  you  a  different  menu,  or 
it  will  execute  a  processor.  In  the  latter  case  you  will  tempor¬ 
arily  leave  the  Command  System  and  be  placed  "in"  the  processor; 
you  will  return  to  the  Command  System  when  the  processor  finishes 
or  you  are  finished  with  it. 

Figure  4-1  shows  the  "TOP"  Command  System  choice  menu,  the 
one  you  see  first  after  giving  the  "ALIAS"  command  after  logging 
on.  The  menu  has  six  choices,  five  of  which  lead  to  display  of 
another  menu.  Command  System  menus  are  organized  in  an  hier¬ 
archical  "tree",  as  shown  in  Figure  4-2,  You  move  down  the  tree 
by  choosing  options  on  successive  choice  menus,  with  the  options 
becoming  more  and  more  specific  as  you  move  down.  Notice  that 
the  "TOP"  menu  is  the  top  of  the  hierarchy  in  Figure  4-2,  and 
that  there  are  five  "branches",  one  for  every  option  on  the  "TOP" 
menu  except  3,  which  causes  the  Data  Base  Updating  system  to  be 
run. 
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Figure  4-1.  Ccciricuid  System  Top  Menu 


Menu  is  TOP 


*  i^IAS  OOMMMID  SYSTEM  *  Scenario  is  EEMO 


TOP  LEVEL  ;^IAS  OOMMAMD  MENU 

1.  CUSTOMIZE  USER  ENVIRCNMENT 

2.  CALL  NON-i^IAS  PBOCESSQRS 

3.  DATA  BASE  UEDATING  SYSTEM 

4.  MANUAL  ASSIGNMENT  EDITOR 

5.  FORCE  LEVEL  REPORT  GENERATOR 

6.  SCENARIO  CHOICE/IAKEUP  SYSTEM 

OOM4AND: 


4-4 


Choice  menus  ace  where  you  get  things  done  in  the  Command 
^stem.  If  you  do  not  see  the  exact  thing  you  want  to  do  listed 
on  you  current  menu,  either  pick  the  option  which  is  in  the  right 
general  area,  or  go  back  to  the  previous  menu.  The  system  map 
shown  in  Figure  4-2  is  also  available  on-line  at  any  time  (give 
the  "?*"  command) . 

There  ace  a  few  things  to  notice  about  the  form  of  choice 
menus.  First,  the  ALIAS  COMMAND  SYSTEM  *"  header  will  always 
appear  at  the  top  of  the  display  in  the  middle.  If  you  do  not 
see  this  header,  you  are  not  in  the  Command  ^stem.  The  name  of 
the  current  menu  will  be  given  at  the  top  left,  and  the  neune  of 
the  scenario  you  ace  using  at  the  top  right.  The  title  appearing 
just  below  the  line  of  dashes  should  give  you  a  general  idea  of 
the  subject  the  menu's  options  are  concerned  with. 

Figure  4-3  shows  an  alternative  version  of  the  "TOP"  menu, 
one  which  includes  reminders  of  the  most  commonly  used  commands 
that  are  available.  You  decide  which  version  of  choice  menus 
will  appear  by  making  a  choice  in  the  User  Environment  Parameters 
menu  (more  on  this  in  Section  4-5) . 

Be  aware  that  the  Command  System  is  a  changing,  growing 
entity.  As  the  number  of  functions  which  ALIAS  supports  grows, 
the  number  of  menus  and  the  options  on  each  one  will  grow. 

4.3.2  £aj:jJiil£££X.J!i£JIUS 

A  sample  parameter  menu  is  shown  in  Figure  4-4.  These 
menus  allow  you  to  make  permanent  changes  to  parameters,  which 
are  variables  controlling  how  some  aspect  of  the  system  works, 
lypically  the  paramc^cers  are  read  by  the  module  they  are  asso¬ 
ciated  with  and  used  during  the  module's  set-up  and  operation. 

The  assignee  reads  those  shown  in  Figure  4-4  to  find  out  how  long 
a  period  the  assignments  table  it  constructs  should  cover,  etc. 


Figure  4**3 .  Top  Menu  With  Goimcmd  Tickler  Displayed 


Menu  is  1DP  *  OOMMAND  SY51EM  *  Scenario  is  DEMO 

pop  to  previous  menu  I  /  pop  to  top  maiu 

reprint  with  curreit  values  I  {+  build  oannand  file 

}  Old  ccoRiand  file  building  I  {  use  camand  file 

?  use  help  processor  I 


1DP  LfVEL  PLItS  OOMMAND  MENU 

1.  OJSIDMIZE  USER  ENVIRONMENT 

2.  CAUi  MON-ALIAS  PROCESSORS 

3.  lATA  BASE  UTOATING  SXSOEM 

4.  MAMJAL  ASSIGNMENT  EDITOR 

5.  FORCE  LEVEL  REPORT  GENERATOR 

6.  SCQIARIO  CHOICE/IAKEUP  SYSTEM 
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Figure  4-4.  Scrapde  Parameter  Menu 


Menu  is  ASNTOM  *  ALIAS  CDMAND  S^TEM  *  Scenario  is  EEMO 

ASSIGN  MODULE  INm^OilZATICN  PARAMETERS 

1.  TIME  UNIT  s  FISCZR  (FISaR«C2^YR,QTIVMCNTH,WEEK,DAy) 

2.  STARTING  DATE  =  10/  1/1985  (l«/ED/my) 

3.  ENDING  DATE  »  9/31/1994  (M^/mY) 

4.  CANDIDATE  SHIP  YARDS  >  LIST  (Ali/LIST) 

5.  CANDIDATE  SHIP  OASSES  «  LIST  (AIlAlST) 

6.  CANDIDATE  JCB  TYPES  -  LIST  (ALI/LIST) 

7.  DISILAY  BASIS  «  AfD  (APPROPrAfD, START,  KEEL,LNCH,DELIV) 

8.  ADJUST  BASIS  «  START  (APH«0P,A^,  START, KEEL,  INCH, DELW) 

9.  ADJUST  MODE  »  PROGRAM  (NONE,  PROGRAM,  ODMPLX-GROUP) 

10.  JCBS  EPOCS  OPnCM  «  IRQJ  (ALL,CUR^PRCa,PRaj} 

11.  ailPOLASS  SORT  ORDER  >  ALfflABETIC  (J^HUSETIC,  INHJT  ORDER) 

12.  SHIPYARD  SORT  ORDER  >  MtEHABETIC  (ALffiJCETIC,  INHJT  ORDER) 

13.  AUTO  REFRESH  >  OFF  (CN,OFF) 

OOIflAND: 


Parameter  menus  were  created  to  save  you  the  burden  of 
answering  a  series  of  tedious  questions  each  time  you  want  to  run 
a  processor  (e.g.  "What  start  date?”,  ”What  end  date?”,  ”What 
time  units?”)  while  still  giving  you  the  freedom  to  make  exact 
specifications  of  how  the  processor  should  work.  Since  the 
parameter  values  are  saved  permanently  as  part  of  the  scenario 
you  are  working  with,  you  need  set  them  only  once  (but  you  can 
make  changes  to  these  settings  whenever  you  want) . 


Thus  the  primary  commands  you  will  give  in  a  parameter  menu 
will  be  to  change  parameter  values.  Such  commands  take  the  form 
”#snew_ value”,  where  #  is  the  number  of  the  parameter  you  want  to 
change  (as  shown  at  the  left  of  the  menu) .  For  example,  to  im¬ 
plement  the  STARTING  DATE  setting  shown  in  Figure  4-4,  you  would 
give  the  command  ”2^10/1/1985”.  Only  one  such  command  can  appear 
on  a  given  line,  i.e.  only  one  may  be  given  in  response  to  each 
"COMMAND:"  prompt. 


There  are  six  kinds  of  parameter,  and  thus  six  formats  in 
which  new  values  can  be  specified: 

1)  CODE  WORDS:  exemplified  by  parameters  1  and  7-13  in 
Figure  4-4,  these  character-^pe  parameters  have  a  list 
of  valid  vcdues,  which  is  given  in  parentheses  following 
the  current  vcdue.  In  changing  the  setting  you  must 
pick  from  the  list. 

2)  DATES:  exemplified  by  pareuneters  2  and  3  in  Figure  4-4, 
these  are  calendar  dates  specified  in  MM/DD/YYYY  format, 
i.e.  with  a  4-digit  century.  If  you  specify  "1/1/88"  by 
accident  the  system  will  take  you  at  your  word  and  think 
you  mean  the  year  A. D.  88. 

3)  YES/NO:  not  shown  on  the  menu  in  the  Figure,  these 
parameters  can  take  on  a  YES  or  NO  (or  TRUE  or  FALSE) 
val ue. 

4)  INTEGERS:  not  shown  in  the  sample  menu,  these 
parameters  must  have  integer  number  values  within  the 
range  shown  in  the  parentheses. 

5)  REAL  NUMBERS:  like  integers,  but  decimal  points  are 
cdlowed. 


6}  LIST  menu  gates:  exemplified  by  parameters  4  through  6 
in  Figure  4-4,  these  parameters  are  concerned  with  lists 
of  items  which  can  have  on-off  statuses.  As  shown  in 
the  example  (in  the  parentheses),  such  parameters  can 
take  on  values  of  "ALL"  or  of  "LIST".  If  ALL,  all 
member  of  the  represented  list  are  "turned  on".  If 
LIST,  you  must  look  at  the  list  menu  to  determine  which 

ones  are  on.  To  cause  the  list  menu  to  be  shown,  just 

re-set  the  parameter  value  to  LIST  with  the  command 
"#»LIST",  even  if  LIST  is  already  the  current  value. 

The  format  of  parameter  menus  is  similar  to  that  of  choice 
menus  in  that  the  top  line  reminds  you  that  you  are  using  the 
Command  System  and  gives  the  name  of  the  menu  and  scenario  you 
are  working  with.  However,  the  numbered  menu  options  are  split 

into  three  parts.  On  the  left,  following  its  number,  each  option 

has  a  label  briefly  explaining  what  the  parameter  is  for.  The 
current  value  is  shown  in  the  middle,  following  the  "»"  sign, 
while  lists  of  valid  values  or  hints  about  value  formats  appear 
at  the  right  in  parentheses. 

4.3.3  List,  ften4S 

The  first  page  of  the  list  represented  by  the  CANDIDATE 
SHIP  YARDS  parameter  on  the  menu  shown  in  Figure  4-4  is  shown  in 
Figure  4-5.  Lists  are  really  just  a  specicd,  multi-valued  type 
of  parameter  which  you  use  to  indicate  the  things  you  want 
processing  done  for.  The  assigner  uses  this  particular  list, 
which  contains  the  names  of  all  the  shipyards  that  the  DEMO 
scenario  has  data  for,  to  determine  which  shipyards  it  should 
load  and  update  assignments  for. 


List  menus  are  the  means  of  making  choices  from  lists.  You 
make  choices  by  turning  some  or  all  of  the  list  members  (called 
candidates)  "on".  Those  that  are  turned  on  have  asterisks  by 
their  names.  To  change  a  candidate's  status,  just  give  its 
number  in  response  to  the  "COMMAND:”  prompt.  If  it  was  off  it 
will  be  turned  on;  if  on  it  will  be  turned  off.  This  toggling  of 
statuses  is  the  main  action  you  can  take  in  list  menus. 
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CB0C6E  1HE  SETT  OF  VALID  YARDS  TO  WHICH  SHIBS  »AY  BE 


ASSICaiED 


1. 

AE  IND 

2. 

AAA  SF 

3. 

AAA  SO 

4. 

ADD6C0 

5. 

iy^IED 

6. 

ANSI?  T 

7. 

AROiTEL 

8. 

ATKINSON 

9. 

A3LAN  CD 

iS/CNDALE 

11. 

BAYSHIP 

12. 

BELC^ALT 

13. 

14. 

Bm  BA 

15. 

besh  key 

16. 

BETH  NT 

17. 

BETH  SF 

18. 

BETH  SP 

19. 

bethbead 

20. 

BETSGST 

21. 

*  BTW 

22. 

BTW  PCRT 

23. 

BOEINGEL 

24. 

BOEINSSE 

QOMAND: 
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A  list  may  have  more  candidates  than  will  fit  on  a  single 
display  page  (the  sample  one  runs  to  four  pagesr  only  the  first 
of  which  is  shown).  You  may  look  at  other  pages  by  using  the 
and  commands  to  page  up  and  down.  List  menus  are  the  only 
ones  in  which  paging  is  allowed. 

List  menus  are  also  unusual  in  that  you  can  effectively 
give  more  than  one  command  on  a  single  line.  For  example,  if  you 
wanted  to  change  the  statuses  of  candidates  4 ,  16 ,  and  20  you 
could  type  "4,16,20"  in  response  to  the  "COMMAND:"  prompt  instead 
of  giving  the  number  one  at  a  time  in  response  to  three  separate 
prompts.  However,  you  can  only  change  the  statuses  of  candidates 
which  appear  on  the  displayed  page. 

The  format  of  list  menus  is  the  standard  one,  with  re¬ 
minders  and  title  at  the  top.  Candidates  appear  in  two  numbered 
columns,  with  asterisks  between  the  number  and  the  candidate  name 
indicating  "on"  status. 


You  can  obtain  on-line  help  from  any  of  the  three  types  of 
Command  System  menu  by  giving  the  "?"  command.  The  response  to 
this  command  will  be  a  fourth  variety  of  "menu",  such  as  that 
shown  in  Figure  4-6,  which  presents  all  of  the  help  options  at 
your  disposal.  A  menu  is  necessary  since  there  are  so  many  kinds 
of  help  available:  descriptions  of  commands,  of  the  subject  the 
menu  you  gave  the  "?"  command  in  is  concerned  with,  help  about 
its  individual  options,  etc. 

You  cannot  take  any  actions  in  help  menus,  you  can  only 
obtain  help.  To  return  to  the  menu  you  were  in  when  you  asked 
for  help  give  the  usual  command. 

4 .3 .5  Summary 

There  are  five  basic  things  you  can  do  in  the  Command 
System:  run  a  processor,  look  at  a  different  menu,  set  a  param¬ 
eter  value,  change  the  on/off  status  of  members  of  a  list,  and 
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Figure  4-6.  H^p  Menu 


Standard  ccmnands  usable  in  the  h^p  subitem  are: 


pop  back  to  previous  menu 
refresh  current  screen 
hdp  for  entire  menu  ^stan 
help  for  previous  menu 
hdp  for  line:#  on  previous  menu 


pop  to  top-most  menu 
disfl^  menu  system  map 
hdp  for  this  help  menu 
hdp  for  previous  standard  options 


HELP  G0M1AND:  M 

Give  the  connand  S  in  the  help  sub^stem  to  find  out  about  ALIAS  and  the 
basic  organization  cf  its  ccomand  ^stem.  You  are  new  positioned  in  the 
topr  or  hichest  level ,  ALIAS  connand  menu.  Other  menus  cire  spread  down  a 
hierarchical  tree  which  you  mey  move  through.  All  menus/f  unctions  m^  be 
reached  ty  a  series  of  connands  which  you  give  starting  fron  this  menu.  Qnrrent 
functions  include  user  environnent  set-upr  an  ability  to  ran 
non-ALIAS  processors  fron  within  ALIAS,  and  a  data  base  mainteneunce 
sub^stem. 


get  help.  Processors  can  be  run  only  from  a  choice  menu.  Choice 
menus  also  offer  the  main  access  to  other  menus,  adthough  list 
menus  must  be  called  up  from  their  "owning”  parameter  menus.  Help 
can  be  had  anytime. 

As  a  user  of  the  Command  System,  you  are  likely  to  spend 
most  of  your  time  with  choice  menus;,  you  will  use  the  parameter 
and  list  menus  only  when  you  want  to  set  up  values  for  a  scenario 
or  make  changes  to  your  set-up.  And  since  the  choice  menus  are 
organized  in  a  tree-like  hierarchy,  you  are  likely  to  use  the 
"TOP"  choice  menu  most  often,  as  you  travel  from  one  branch  to 
another. 

4.4  AVAILABLE  COMMANDS 

As  mentioned  above,  there  are  numeric,  non-numeric,  and 
setting  types  of  commands.  The  meaning  of  the  numeric  commands 
changes  with  the  menu;  the  form  of  settings  are  also  determined 
by  the  individual  menu.  However,  there  are  several  "house¬ 
keeping”  commands  which  perform  additional,  useful  functions. 

This  section  will  present  those  commands. 

4.4.1 

Universal  commands  are  those  which  can  be  given  (with  the 
same  meaning)  in  any  menu.  These  include: 

The  upwards  caret  tells  the  Command  System  to  "pop"  or 
return  to  the  menu  it  displayed  just  before  the  current 
one.  Choice  menu  options  are  the  principal  means  of  moving 
down  the  Command  System  tree  of  menus;  the  caret  is  the 
principal  means  of  moving  back  up  again. 

?  The  universal  ALIAS  help  request.  In  the  Command  ^stem 

the  response  will  be  a  menu  of  the  kinds  of  help  which  are 
available.  The  menu  that  appears  is  tailored  to  the  type 
of  menu  the  help  request  was  issued  in. 

?x  You  can  bypass  the  help  menu,  if  you  know  the  exact  kind  of 
help  you  want,  by  postscripting  the  *?"  character  with  the 
request  character  which  appears  on  the  help  menu  for  that 
kind  of  help.  Thus  ?*  displays  the  system  map,  ?M  tells 
you  about  the  menu  you're  in,  ?#  tells  you  about  option  # 
on  the  menu  you're  in,  etc.  As  you  learn  to  use  the  system 


make  sure  to  ask  for  help  from  each  different  kind  of  menu 
so  you  become  aware  of  the  sorts  of  help  that  are 
available. 

&  If  for  some  reason  the  display  has  become  garbled,  or  part 
of  a  menu  has  scrolled  off  the  top,  you  can  ask  for  a 
re^display  of  the  menu  by  giving  the  command. 

/  Pops  you  to  menu  "TOP".  Since  the  "TOP"  menu  occupies  a 
special  place  at  the  top  of  the  menu  hierarchy,  you  are 
likely  to  want  to  get  to  it  often.  This  special  command 
jumps  you  back  to  it  no  matter  how  far  down  the  tree  the 
menu  you  are  currently  using  is. 

Q  Either  of  these  commands  can  be  used  to  terminate  your 
E  Command  ^stem  session.  Not  accepted  in  help  menus. 

{  The  "bracket"  commands  ask  for  various  services  from  the 

}  stored  commands  (or  "command  file")  subsystem,  which  is 

{+  discussed  in  more  detail  in  Section  4.6.  {  invokes  the 

{-  stored  command  use  facility;  {name  executes  a  particular 

{  name  stored  command;  {+  starts  the  stored  command  creation 
process,  while  }  ends  it;  and  {-  allows  you  to  delete 
stored  commands  which  you  created.  These  commands  are  not 
accepted  in  help  menus. 

Note  that  only  one  command  is  accepted  at  a  time,  i.e.  you 
are  limited  to  one  command  per  "COMMAND:"  prompt,  except  in  list 
menus . 


4.4.2 

In  addition  to  those  just  presented,  four  additional  com¬ 
mands  are  accepted  in  list  menus: 

+  This  is  a  request  for  the  next  page  of  the  list. 

This  is  a  request  for  the  previous  page  of  the  list. 

A  This  sets  the  status  of  all  candidates  to  "on",  including 
those  on  pages  of  the  list  not  currently  shown.  This 
command  and  the  next  one  are  exceptions  to  the  general  rule 
that  you  must  be  able  to  see  a  candidate  to  change  its 
status. 

N  This  sets  the  status  of  all  candidates  to  "off". 

When  making  changes  in  a  list  menu,  you  are  likely  to  want 
either  to  turn  all  candidates  "on"  or  to  have  only  a  few  "on". 

The  "A  "and  "N"  commands  ease  the  tedium  of  performing  this  task. 
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For  example,  to  convert  a  situation  in  which  all  candidates  of  a 
list  are  "on”  to  one  in  which  only  few  are,  the  easiest  means  is 
by  using  "N"  to  turn  all  "off",  followed  by  giving  the  numbers  of 
those  few  which  are  to  be  "on". 


4.4.3 

In  addition  to  the  universal  commands,  help  menus  respond 
to  a  set  of  commands  which  correspond  to  the  kinds  of  help  avail 
able: 


M  Requests  display  of  the  text  description  of  the  purpose  of 
the  choice,  parameter,  or  list  menu  you're  in. 

*  Requests  that  the  system  map  (Figure  4-1  or  similar  to  it) 
be  displayed. 

C  Requests  a  description  of  each  of  the  commands  that  are 

available  in  the  choice,  parameter,  or  list  menu  you're  in. 

S  Requests  that  the  ALIAS  system  description  (an  introductory 
summary  of  what  ALIAS  does  and  how  to  use  it)  be  displayed. 

?  Given  in  this  context,  "?"  causes  a  description  of  how  the 
help  subsystem  works  to  be  displayed. 

#  where  "#"  is  the  number  of  one  of  the  options  on  the 
choice,  parameter,  or  list  menu  you're  using.  This  causes 
a  text  description  of  the  purpose  and  result  of  the  option 
to  be  displayed. 

4.5  ENVIRONMENT  OPTIONS  AND  UTILITY  PROGRAM  ACCESS 

IVo  of  the  branches  of  the  Command  ^stem  menu  tree  do  not 

lead  to  modules,  but  rather  provide  access  to  overall  Command 

^stem  control  values  and  to  utility  programs. 


Option  1  on  menu  "TOP"  leads  to  the  "ENVIRONMENT  CONTROL" 
menu,  whose  first  option  in  turn  leads  to  the  "USER  ENVIRONMENT 
PARAMETERS"  menu,  shown  in  Figure  4-7.  At  present  you  may  set 
three  things  in  this  menu:  the  ^pe  of  terminal  you  are  using, 
the  printer  you  want  your  reports  to  come  out  on,  and  whether  or 
not  you  want  the  reminder  of  commonly  used  commands  to  appear  at 
the  top  of  your  Command  System  menus.  Note  that  most  modules 


Figure  4-7.  User  Environnent  iferameters  Menu 


Menu  is  EWJN  *  CDMMftND  SYSTEM  *  Scenario  is  EEMD 


USER  EN7IBCNMEMT  PARAMETTERS 

1.  TERMINAL  TYPE  =  SBRAIN  {HP2623  ,ffiRAINrIE15,IEl4,HP2647  ,PC 

2.  DEVICE  TD  ERINT  TD  =  TERMINAL  (TERMINAL,  DAISY, LP,ERINTER) 

3.  ERINT  GDM1ANDS  CN  MENDS?  =  NO  (YES,NO) 

OOraiAND: 
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consult  the  "DEVICE  TO  PRINT  TO"  parameter  when  they  are  ready  to 
print,  giving  its  setting  a  system-wide  effect. 

Option  2  on  the  "ENVIRONMENT  CONTROL"  choice  menu  is  for 
system  development  and  maintenance  personnel,  and  should  be  used 
only  by  them. 

Option  2  on  menu  "TOP"  leads  to  the  "HP  PROGRAMS"  choice 
menu  (shown  in  Figure  4-8),  in  which  you  may  request  to  use  any 
of  several  programs  generally  availeU>le  on  the  HP,  such  as  the 
editors  and  graphics  package.  Note  that  only  Data  Base  Admin¬ 
istrators  will  be  permitted  to  use  RELATE  (option  4}  and  MENU 
(option  5)  this  way. 

It  is  particularly  convenient  to  have  access  to  an  editor 
without  leaving  ALIAS,  since  this  eQlows  you  to  quickly  perform 
such  tasks  as  sending  mail  to  other  users  and  altering  Force 
Level  report  format  control  files. 

4.6  STORED  COMMANDS 

You  may  become  impatient  with  a  command  system  which  prints 
out  voluminous  menus  at  each  step.  Stored  commands  offer  a  means 
of  bypassing  the  menus. 

A  stored  command  is  a  series  of  ALIAS  commands,  perhaps 
given  in  a  series  of  severed  menus,  which  can  be  invoked  by  name 
from  a  particular  menu.  Thus,  if  you  want  to  use  the  TDP  editor 
and  you  are  in  the  "TOP"  menu,  you  can  give  the  command  "{TDP"  as 
an  alternative  to  choosing  option  2  and  then  option  2  in  the  HP 
PROGRAMS  menu.  The  stored  command  gives  the  commands  "2"  and 
”/".  It  bypasses  disple^  of  the  menu,  places  you  in  TDP,  and 
then  returns  you  to  menu  "TOP"  when  you  exit  TDP. 

Individual  stored  commands  are  not  built-in  parts  of  ALIAS, 
but  rather  are  created  by  indivldu2d  users  as  they  see  fit  (all 
commands  created  by  all  users  are  available  to  everyone)  . 


Figure  4~8.  Utility  Arogrem  Aooess  Menu 


Mmu  is  HPBOGS 


*  i^IAS  GOMNMID  SY51EM  *  Scenario  is 


If  you  know  the  neone  of  the  stored  command  you  want  to 
executer  you  can  just  give  it  as  a  command  prefixed  the 
character.  To  find  out  what  stored  commands  are  available,  give 
the  character  all  itself. 

Creation  of  a  stored  command  is  a  straightforward  task  in 
which  you  step  through  the  procedure  you  want  stored.  You  must 
get  to  the  menu  you  will  want  to  use  the  command  in  after  it  is 
created,  and  then  give  the  command  to  start  the  building 

process.  You  will  be  prompted  for  a  name  and  a  description,  and 
then  returned  to  the  given  choice,  parameter,  or  list  menu  (a 
message  will  appear  at  the  upper  right  corner  to  remind  you  that 
you  are  building  a  stored  command) . 

Just  step  through  the  process  you  want  to  record.  Note 
that  stored  commands  apply  only  in  the  Command  System,  not  in  any 
other  modules  or  processors.  Thus,  if  you  run  the  assigner  as 
part  of  your  procedure,  any  actions  you  take  in  the  assigner  will 
not  be  part  of  the  stored  command.  Instead,  when  you  later 
execute  it,  the  command  will  "pause"  as  it  executes  the  assigner, 
letting  you  perform  any  action  you  wish  there,  and  resume  when 
you  leave  the  assigner. 

Be  aware  that  any  changes  made  to  parameter  or  list  menu 
settings  will  k>ecome  part  of  the  stored  command  and  thus  will  be 
repeated  each  time  it  is  executed  in  the  future. 

When  you  have  finished  your  procedure  and  are  in  the  menu 
you  want  the  stored  command  to  leave  you  in  when  it  ccxnpletes, 
give  the  "}"  command.  This  completes  the  creation  process  and 
makes  the  new  command  available. 

You  can  invoke  a  stored  command  deletion  processor  lay 
giving  the  "{-"  command.  You  will  only  be  allowed  to  delete 


those  that  you  created,  not  those  created  by  others  (unless  you 
are  a  Data  Base  Administrator  level  user) . 

There  are  two  Important  limitations  of  stored  commands. 
First,  they  can  only  be  executed  from  the  Command  ^stem  menu  in 
which  their  creation  began.  Thus,  one  cannot  execute  the  "TDP" 
command  from  the  assigner's  parameter  menu.  It  is  usually  most 
convenient  to  start  general-purpose  stored  commands  from  menu 
"TOP”,  since  "TOP"  can  be  jumped  to  immediately  from  anywhere 
using  the  ”/”  built-in  command. 

Second,  ar^  mistakes  you  make  while  constructing  a  stored 
command  become  a  part  of  it,  so  be  careful  during  the  creation 
process  1 


4.7  SUMMARY:  A  GUIDED  TOUR  OF  COMMAND  SYSTEM  MENUS 

Table  4-1  summarizes  the  commands  you  can  give  while  in  the 
Command  System.  The  remainder  of  this  section  presents  the  menus 
available  in  ALIAS  Version  1.0,  with  running  commentary  on  their 
purposes,  in  the  same  general  format  as  used  in  Section  3. 


Table  4-1.  Sununacy  of  Conunand  System  Commands 


COMMAND 

USABLE 

number 

choice 

list 

f^vadue 

param. 

? 

anywhere 

?* 

m 

?# 

m 

?C 

m 

?M 

m 

?S 

m 

?? 

m 

Q  or  E 

anywhere 

A 

anywhere 

anywhere  r 

/ 

anywhere 

{ 

anywhere 

{name 

anywhere 

{+ 

anywhere 

} 

a  ly  where 

{- 

aiywhere 

EFFECT 


executes  choice  menu  option  # 
toggles  the  status  of  list  candidate  # 
set  parameter  #  to  a  new  value 

disple^  of  a  menu  of  help  options 
displ^  of  the  system  map 
description  of  menu  option  # 
review  of  available  commands 
description  of  the  current  menu 
description  of  ALIAS 

description  of  how  to  use  the  help  subsystem 
exit  the  Command  System;  return  to  MPE 
return  to  the  menu  displayed  before  this  one 
e-displ^  the  current  menu 
go  back  to  menu  TOP 

enter  stored  command  execution  subsystem 
execute  stored  command  "name”  ("name”  will 
be  executable  from  only  one  menu) 
start  creating  a  new  stored  command 
complete  creation  of  a  stored  command 
delete  stored  commands 


+  list  menu  display  the  next  page 

list  menu  display  the  previous  page 

A  list  menu  turn  "on"  all  list  candidates 

N  list  menu  turn  "off”  adl  list  candidates 


On  the  facing  page  the  TOP  menu  is  shown  in  the  top  frame, 
while  the  system  map  pictorially  displays  the  branches  the  TOP 
options  lead  to.  Note  that  the  map  was  displaced  in  response  to 
the  ”?*”  quick  help  request. 

This  tour  will  work  its  way  down  each  branch  of  the  menu 
tree  in  the  order  in  which  they  appear  on  the  top  menu. 


The  "Environment”  branchy  which  starts  with  option  1  of 
TOPr  is  for  setting  some  system**wide  control  variables  which 
influence  your  work.  You  must  go  through  the  "Environment 
Control"  menu  to  get  to  the  "User  Environment  Parameters"  menu 
which  has  these  control  values.  Option  2  of  the  "Environment 
Control  menu  should  be  used  only  by  software  developers. 

Ihe  "Environment  Parameters”  menu  is  the  one  to  go  to  if 
ALIAS  is  not  clearing  your  terminal's  display  before  it  types 
each  menu;  ALIAS  may  have  made  a  poor  guess  about  the  make/roodel 
of  the  terminal  you  are  using. 

You  can  also  choose  which  printer  your  hard  coipy  output 
will  appear  on  in  this  menu,  and  whether  or  not  command 
"ticklers"  will  appear  at  the  top  of  menu  displays.  They  are 

appearing  in  this  set  of  samples - note  that  option  3  started  out 

set  to  "YES",  was  set  to  "NO"  by  a  command,  and  then  set  back  to 
"YES"  again. 

The  ”/"  command  causes  a  return  to  the  TOP  menu  (so  we  can 
go  down  the  next  branch) . 


OOP  ;C.IAS  GOMMMID  MEND 

CDSIDMIZE  USER  ENVIRONMENT 
CAEl.  NON-i^IAS  PIOCESSQRS 
DATA  BASE  UFDATINS  SXSTEN 
MANUAL  ASSIGNMENT  EDITOR 
force  levo.  report  GENER/ODR 
SCENARIO  (SOICE/MAKEUP  S^IEM 


GOfMAND:! 


Menu  is  ENVIRC  *  ALIAS  ODIffAND  SYSIEM  *  Scenario  is  EE 

''  pop  to  previous  mam  I  /  pop  to  top  menu 

&  reprint  with  current  values  j  {-f  build  ccnmand  file 

}  end  ccoinand  file  building  I  {  use  ccnmand  file 

?  use  help  processor  I 


ENVIRONMENT  CCNTRDL 

1.  EXA^IRGNMQIT  EARAMETERS 

2.  SET  LPINTS  (DEBUG  SNITCSES) 

CDfMVND:! 


Menu  is  ENVIN  *  ALIAS  OOMAND  SYSTEM  *  Scenario  is  EEMO 

pop  to  E«:evious  mom  I  /  pop  to  top  mom 

&  reprint  with  curroit  values  !  {+  build  ccnmand  file 

}  Old  ccnmand  file  building  I  {  use  ccnmand  file 

?  use  help  processor  I 


USER  ENVIRONMENT  PARAMET^ 

1.  TERMINAL  TZPE  «  SBRAIN  (HF2623rSRAlN,I&15rBZl4rHF2647rPC 

2.  DEVICE  TD  HUNT  TO  «  TERMINAL  (TERMINALrDAISY,LP,ERIMTER} 

3.  HUNT  GOMANDS  CN  MENUS?  «  YES  (YES,NO) 

G0MAND:?3 

Allows  you  to  turn  off  the  tickler  print  at  the  tqp  of  each 
menu  cf  the  most  used  ALIAS  menu  system  ccnmands. 

GDMAND:>N 
COMMAND:  >Y 
ODMAND:/ 


Saving  parameter  settings... 


The  ”Non-ALIAS  Processors”  branch  provides  a  way  to  execute 
some  commonly  used  programs  without  leaving  the  Command  System. 
The  ”HP  Programs”  menu  listing  the  ones  available  is  displayed  by 
choosing  option  2  in  TOP. 

EDITOR  and  TDP  are  text  editors,  and  GRAPH  the  HP  business 
graphics  package.  RELATE  and  MENU  run  the  DBMS,  but  security 
restrictions  may  prevent  you  from  choosing  these  options.  SPOOK 
is  an  HP  prog reun  for  managing  spooled  print  files;  it  can  be 
useful  for  checking  the  progress  of  any  printouts  you  have 
started. 


Menu  is  TOP  *  ALIAS  OOMIAND  SYSTEM  *  Scenario  is  EEMD 

pop  to  previous  menu  i  /  pop  to  top  moiu 

&  reprint  with  curr^  values  I  {-('  build  ocninand  file 

}  aid  ccnmand  file  building  I  {  use  ccomand  file 

?  use  help  processor  i 

TOP  l^Bm.  ALIAS  CDMMAMD  MENU 

1.  OJSIDMQE  USEZl  ENVIRQNMEirr 

2.  CAUi  non-m:.ias  PBOCESSQRS 

3 .  EATA  BASE  UPDATING  SYSTEM 

4.  MAMJAL  ASSIGNMENT  EDITOR 

5.  FORCE  LEVEL  REPORT  GENERATOR 

6.  SCENARIO  CBOICE/IAKEUP  SYSTEM 

CX)N1AND:2 


Menu  is  HPR06S  *  ALIAS  OOMAND  SYSTEM  *  Scenario  is  CEMO 

''  pop  to  previous  menu  I  /  pop  to  top  menu 

&  reprint  with  current  values  I  {+  build  ocninand  file 

}  end  ccnmand  file  building  I  {  use  ccnmand  file 

?  use  help  processor  I 


The  third  branch  leads  directly  to  the  Data  Base  Updating 
System.  The  DBU  is  the  subject  of  Section  7. 

The  fourth  branch  services  the  assigner,  and  is  the  largest 
in  terms  of  number  of  Command  System  menus  (there  are  five).  In 
the  first  of  these  you  may  choose  either  to  run  the  assigner  or 
to  inspect  its  control  variable  values.  The  latter  was  chosen  in 
the  sample;  the  assigner' s  parameter  menu  is  displayed  at  the 
bottom.  The  assigner  looks  at  the  vedues  of  the  parameters  dis¬ 
played  as  it  is  running;  you  can  customize  its  operations  for 
your  purposes  by  choosing  the  most  appropriate  set  of  veilues. 

Three  list  menus  are  accessible  from  this  parameter  menu. 
The  one  with  the  list  of  "CANDIDATE  SHIP  YARDS"  is  requested  in 
the  sample. 
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Menu  is  TOP  *  ALIAS  CDMAND  SYSTEM  *  Scenario  is  EEMO 

pop  to  previous  menu  i  /  pop  to  top  menu 

&  reprint  with  current  values  I  {-<■  build  ocmnand  file 

}  end  coninand  file  building  i  {  use  comnand  file 

?  use  help  processor  I 


1DP  LEm.  ALIAS  Q0MM2WD  MEND 

1.  OJSIDMIZE  USER  QA^IRCNMOfT 

2.  CAU.  NON-ALIAS  PEOCESSQBS 

3.  DATA  BASE  UPDATINS  SYSTEM 

4.  MANUAL  ASSIGNMENT  EDITOR 

5.  EORCE  LEVEL  BEPORT  GENERATOR 

6.  SCENARIO  CHOICX/IAKEDP  SYSTEM 


G0(t1AND:4 


Menu  is  ASSIGN  *  ALIAS  GOMAND  SYSTEM  *  Scenario  is  EEMO 

pop  to  previous  menu  I  /  pop  to  top  menu 

&  reprint  with  curra±  values  I  {-i*  build  ocmnand  file 

}  end  CGoinand  file  building  I  {  use  comnand  file 

?  use  help  processor  I 


MANUiO.  ASSIGNER  SEEaUCATIGMS 

1.  ASSIGNER  INITIALQATICN  PARAMETERS 

2.  EXECUTE  THE  ASSIGNER 

OOMIAND:! 


Menu  is  ASNIRN  *  ALIAS  QOMAND  SYSTEM  *  Scenario  is  EEMO 

pop  to  ^evious  menu  I  /  pop  to  top  mmiu 

&  reprint  with  current  values  I  {■<'  build  ocmnand  file 

}  end  comnand  file  building  i  {  use  comnand  file 

?  use  help  processor  I 


MANJAL  ASSIGNER  MUDOiE  INITIALlZiaiCN  PARAMETERS 


1.  TIME  UNIT 

■  EISCYR 

(FISCYR,  CALYR,C2TRr  MGNTHr  WEQC,  DAY) 

2.  startug  date 

-  10/  V1985 

(MVCD/ttYY) 

3.  QIDINS  DATE 

-  9/33/1994 

(MVTD/YYYY) 

4.  CMIDIOATE  SHIP  YARDS 

.  list 

(Ali/LIST) 

5.  CANDIDATE  SHIP  CLASSES 

s  list 

(ALI/LIST) 

6.  CMIDIDATE  JCB  TYPES 

«  LIST 

(AU/LIST) 

7 .  DISPLAY  BASIS 

s  An> 

(APPROP,  nm,  START,  KEEL,  INCH,  EELIV) 

8.  ADJUST  BASIS 

m  START 

(APPROP,  A7D,ST3«T,  KEEL,IHCH,  DQ.IV) 

9.  ADJUST  MODE 

«  FROGRAM 

(NCNE,  FROGRAM,  GOMFLX-GROUP) 

10.  JCBS  EPOCH  OPnON 

-  PRQJ 

(ALL,  CDREV'PRCa,  PRCJ) 

11.  SIPCLASS  SORT  OREER 

«  ALPHABETIC 

(ALFHABETIC,]NFUT  OREER) 

12.  SIPYARD  SGRT  CRDER 

>  ALIHABEnC 

(ALFHABEnC,  INPUT  CRDER) 

13.  AUTO  REFRESH 

m  off 

(ON,  OFF) 

G0MAND:4«L 
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Only  the  first  page  of  this  (currently)  four-page  list  is 
shown.  The  assigner  will  load  and  permit  entry  of  assignments 
only  for  yards  which  are  "turned  on”  in  this  list  (only  for  BIW 
in  this  case) . 

Exiting  this  list  brings  the  parameter  menu  back  up  again 
where  a  request  for  the  next  list  is  issued. 


Menu  is  CBSns  *  ALIAS  CDIM 

pop  to  previous  menu  I 

&  print  screen  with  current  values  I 

N  no  items  are  INCUJEB)  I 

print  previous  list  screen  I 


CB0G6E  IHE  SET  OF  Vi^ID 


*  ALIAS  CDMAND  SYSTfM  *  Scenario  is  EEMO 


I  /  pop  to  top  mmiu 
I  A  all  items  are  ]MC1.UEED 
I  ?  help  for  this  moiu 
I  'f  print  follow ine  list  screai 


ID  WHICB  SBIFS  fAY  BE  ASSIGNS) 


Menu  is  ASNHUl  *  ALIAS  QOMMAND  SY51EN  *  Scenario  is  EEMO 

pop  to  previous  menu  I  /  pop  to  top  menu 

&  reprint  with  currat  values  I  {+  build  conmand  file 

}  end  command  file  building  I  {  use  command  file 

?  use  help  processor  I 


MAHIAL  ASSIGNER  NODCLE  INITIALIZATICN  PARAMETTBS 


1.  TIME  UNIT 

•  FISCXR 

(FISCIR,  CALYR,QlRr  MONTH,  WEEK,  EAY) 

2.  STARTQG 

-  10/  3/1985 

(MVCD/WYY) 

3.  ENDING  DATE 

-  9/33/1994 

(IH/tD/mY) 

4.  CNtDIDAOE  SHIP  YARDS 

-  LIST 

(AEI/LIST) 

5.  CANDIDATE  SHIP  CLASSES 

m  list 

(ALE/LIST) 

6.  CMDIDAOE  J(B  TYPES 

a  list 

(AU/LIST) 

7.  DISELAY  BASIS 

-  AfD 

(APEROP,  AH),  START,  KEEL,  UXH,  EELIV) 

8.  AEOUST  BASIS 

a  START 

(APFROP,  A«D,  START,  KEEL,LNCH,  DELIV) 

9.  ADJUST  MODE 

«  ER06RAM 

(NONE,  ER06RAM,  OOMELX-GROUP) 

10.  JCBS  EPOCH  OPTION 

«  PRCU 

(ALL,  OUREV^PROJ,  PRQJ) 

11.  SHIPdiASS  SORT  OREER 

-  alihabetic 

(ALEHABEnC,  INEUT  OREER) 

12.  SHIPYARD  SORT  ORDER 

«  ALEHABEnC 

(ALEHABEnC,  INEUT  ORDER) 

13.  AUTO  REFRESH 

a  off 

(ON,  OFF) 

The  "CANDIDATE  SHIP  CLASSES"  list  has  the  nanes  of  all  ship 
classes  for  which  there  is  data  in  the  current  scenario.  As  with 
the  yards  listr  the  assigner  will  load  and  permit  entry  of  as¬ 
signments  only  for  classes  which  are  "on".  In  this  case,  they 
all  are. 


Menu 

A 

& 

N 


is  CHSCLS  *  ALIAS  OOMAND 

pop  to  previous  inaiu  I  / 

print  screen  with  current  values  I  A 
no  items  are  INQXJEED  i  ? 

print  previous  list  screen  I  -t 


SYSTEM  *  Scenario  is  CEMD 
pop  to  top  menu 
all  items  are  INCLOEED 
help  for  this  menu 
print  follow ine  list  screen 


CB0C6E  1HE  SET  OF  V«iID  SHIP  (LASSES  WHICS  MAY  BE  ASSIGMQ) 


1.  *  AD-14 

2.  *  AD-37 

3.  *  AD-41 

4.  *  AE 

5.  *  AE-21 

6.  *  A&-23 

7.  *  AB-26 

8.  *  AP-58 

9.  *  AfDM 

10.  *  APS-1 

11.  *  AFS-8 

12.  *  AG 


13.  *  AGC6-1 

14.  *  AK-279 

15.  *  AK-280 

16.  *  AK-286 

17.  *  AK-85 

18.  *  AO-105 

19.  *  AD-143 

20.  *  AO-177 

21.  *  AO-177.2 

22.  *  AO-187 

23.  *  AO-22 

24.  *  AO-51 


OOfMAND:^ 

Saving  list  on/off  settings... 


Menu  is  ASNESM  *  ALIAS 

pop  to  previous  menu 
&  reprint  with  current  values 
}  end  conmand  file  building 
?  use  help  processor 


OOWAND  SYSTEM  *  Scenario  is  EBMD 
]  /  pop  to  top  menu 
I  build  ocomand  file 
I  {  use  coomand  file 


lANJAL  ASSIGNER  MODULE  IMlTIiLlZATICM  PARAMEnEI^ 


1.  HME  UNIT 

*  FISCYR 

(FISCXR,  CALYRrQTR,  MONTH,  WEEKr  DAY) 

2.  stafthg  date 

-  10/  3/1985 

(m/tD/YYYY) 

3.  ENDING  DATE 

-  9/33/1994 

(MVtoAXW) 

4.  (SttlDIDATE  SIP  YARDS 

-  LIST 

(ALI/LIST) 

5.  CANDIDATE  SIP  CLASSES 

a  list 

(ALI/LIST) 

6.  (TOIDIDATE  JCB  TYPES 

a  list 

(ALI/LIST) 

7.  DISHiAY  BASIS 

-  AMD 

(APFROP,  JtiD,  SIART,  KEEL,  INS,  DELIV) 

8.  ADJUST  BASIS 

a  START 

(APPROP,AfD,  START,  KEEL,LNCS,  DELIV) 

9.  ADJUST  MODE 

-  ER06RAM 

(NONE,  ER06RAM,  GOMELX-CSROUP) 

10.  JCBS  EPOCS  OFTKXI 

-  PRCJ 

(ALL,  SRE/PROJ,  PROJ) 

11.  SIPCLASS  SORT  ORDER 

«  MtEHABETIC 

(ALEHABEnC,  INHJT  ORDER) 

12.  SHIPYARD  SORT  ORDER 

>  iLEBABEmC 

(ALEHABETIC,  INEUT  ORDS) 

13.  AJTD  REERES 

«  OFF 

(ON,  OFF) 

(X>fMAND:6«L 


The  "CANDIDATE  JOB  TYPES*  list  has  the  names  of  all  the  job 
types  for  which  there  is  data  in  the  current  scenario. 

The  general  capability  to  restrict  the  range  of  yards/ 
classes/job  types  the  assigner  will  work  with  can  be  useful  in 
two  major  weys.  First »  putting  on  restrictions  which  limit  the 
assigner  only  to  the  things  you  are  interested  in  reduces  the 
volume  of  data  you  must  page  through,  saving  time.  Second,  it 
makes  the  assigner  run  faster  because  it  need  not  load  and  update 
as  much  of  the  data  base. 
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Menu  is  CBJTSP  *  ALIAS  QOMAND  SYSTEM  *  Scenario  is  CBMO 

*  pop  to  previous  menu  I  /  pop  to  top  menu  _ 

6  print  screen  with  current  values  I  A  edl  items  are  INCLUDED 

N  no  items  are  INCUJEQ)  I  ?  hdp  foe  this  menu 

print  previous  list  screen  I  print  follcwine  list  screen 

CH0C6E  OHE  SET  OF  VALID  JCBS  WHICH  MAY  BE  ASSIGNED 

1.  *  OWV  5.  *  REPAIR 

2.  *  NEWCON  6.  *  £LEP 

3.  *  REACT  7.  *  SLPCW 

4.  *  REETJEL 


The  fifth  Conunand  System  branch  is  for  the  Force  Report 
Generators.  Choosing  option  5  in  menu  TOP  causes  the  "FORCE 
LEVEL  GENERATOR"  menu  to  be  displayed.  This  menus  offers  a 
choice  between  execution  of  the  Force  Level  report  generator,  the 
Battle  Group  report  generator,  and  inspection  of  the  control  var¬ 
iable  values  to  which  each  of  these  programs  will  pay  attention. 
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Menu  is  TOP  *  ALIAS  QOtWAND  SYSTEM  *  Scenario  is 

A 

pop  to  previous  maiu 

1  / 

pop  to  top  menu 

& 

reprint  with  currmit  values 

1  {+ 

build  oomnand  file 

} 

end  ccmnand  file  building 

1  { 

use  ccmnand  file 

? 

use  help  processor 

1 

IDP  ^lAS  CDMMnn}  MEND 

OJSIDMIZE  USER  El^IBOMMElfr 
CAU.  NCM-ALIAS  FEOCESSORS 
EAXA  BASE  DHATINS  SXSIEM 
MANJiffi  ASSDaiMENT  EDITCR 
FORCE  LEVEL  REPORT  GENERATOR 
SCENARIO  CBOICE/MAKEUP  SYSTEM 


00N1AND:5 


Menu  is  ELRPIG  *  ALIAS  00)tS\ND  SYSTEM  *  Scenario  is  EEMO 

pop  to  previous  menu  I  /  to  top  menu 

reprint  with  current  values  I  {+  build  ccmnand  file 

end  coonand  file  building  I  {  use  ccmnand  file 

use  help  processor  I 


These  report  generators  have  a  somewhat  shorter  list  of 
control  variables,  and  only  a  single  list  menu.  The  list  menu 
displays  the  job  type  codes  for  repair  jobs.  An  asterisk  next  to 
a  code  (implying  status  »  "on”)  indicates  that  the  given  repair 
job  will  cause  ships  undergoing  this  repair  to  be  undeployable 
while  the  repair  work  is  being  performed. 


Menu  is  FLISTT  *  ALIAS  ODftAND  SYSISM  *  Scenario  is  DEMO 

pop  to  previous  menu  I  /  pop  to  top  menu 

&  reprint  with  current  values  1  {+  build  ocoinand  file 

}  end  CGomand  file  building  I  {  use  cacDiand  file 

?  use  help  processor  I 


FGBCE  L£VIL  fm  BATILBGBODP  REKRT  GQIStATCR  PARAMEIESS 


KEEP  REPORT  CN-LZNE  «  YES 

REPORT  START  -  V  V1986 

REPORT  END  DA!IE  -  1^3V1999 

RETIRE  aiPS  BY  «  LIFE 

TIME  PERIOD  L£K?m  «  CALYR 

IN  FORCE  DAY  >  END 

PROGRAM  MILE510ME  «  APPROP 

OUT  OF  FORCE  REPAIR  JOBS  -  LIST 


(YES,  NO) 

(MVlD/XYYY) 

(jfVtiDA^nnf) 

(LIFE,DA3E) 

(DAY,  WEEK,  MXnHrQOR,  CALYR) 
(BBSIN,END) 
(AP!EROP,An3,EeLIV) 
(AU/LIST) 


OOFMAND:»iL 


Menu  is  ELREPT 


*  ALIAS  OOMAND  SYSTEM  *  Scenario  is  CEMO 


pop  to  previous  menu  I 
print  screen  with  current  values  I 
no  items  are  INQIJOED  i 
print  previous  list  screen  I 


REEDOi 

REPAIR 


pop  to  top  menu 
all  items  eu:e  INCLUEED 
help  for  this  menu 
print  fellow ine  list  screen 


BffiCDTION 


A  SBIP 

m 

FQROS 

3.  *  SLEP 


OOMAND:/ 

Seving  list  on/off  settings... 
Saving  parameter  settings... 
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The  last  branch  of  Command  ^stem  menus,  accessed  through 
option  6  of  menu  TOP,  services  the  scenario  system.  During  a 
session  you  may  finish  using  a  scenario  and  wish  to  use  another. 
You  need  not  leave  the  Command  System  and  re-run  it  to  do 

this - just  choose  option  1  on  the  Scenario  System  menu.  Option 

2  lets  you  create  new  scenarios,  while  3  lets  you  delete  them; 
with  6  you  can  change  their  composition  (perhaps  drawing  some 
data  into  the  one  you  are  working  with  from  another).  Options  4 
and  5  lists  the  scenarios  in  existence  either  to  the  terminal  or 
the  printer. 
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Menu  is  TOP  *  ALIAS  GOM1AND  SYSTEM  *  Scenario  is 

pop  to  previous  menu  I  /  pop  to  top  menu 

&  reprint  with  current  values  I  {-(■  build  ccmnand  file 
}  conmand  file  building  I  {  use  cannand  file 

?  use  help  processor  I 


TOP  LEVEL  ALIAS  COMMAND  MEND 

1.  CUSTOMIZE  USES  ENVIRCNMENT 

2.  GAEL  NON-ALIAS  PROCESSORS 

3.  DATA  BASE  UTOATINS  SYSTEM 

4.  MANUAL  ASSIGNMENT  EDITOR 

5.  EORO;  LEVEL  REPORT  GENERATOR 

6.  SCENARIO  OKHOB/MAKEUP  SYSTEM 


OO^t1AND:6 


Menu  is  SCEN  *  ALIAS  OOmAND  SYSTEM  *  Scenario  is  CEMO 

pop  to  previous  menu  I  /  pop  to  top  menu 

reprint  with  curreit  values  I  {+  build  cannand  file 

end  cannand  file  building  I  {  use  caimand  file 

use  help  processor  I 


SCENARIO  SYSTEM  MENU 

1.  CB0G6E  A  DIETERENT  SCENARIO  TO  WORK  WITH 

2.  CREATE  A  NEW  SCENARIO 

3.  EELETE  CURRENTLY  EXISTING  SCENARIOS 

4.  LIST  CURRENTLY  EXISTING  SCENARIOS 

5.  SEND  LIST  OF  EXISTING  SCENARIOS  TO  LINE  PRINTER 

6.  MODIFY  TEE  MAKEUP  OF  AN  EXISTING  SCENARIO 


OOmAND:/ 


This  tour  of  Command  System  menus  has  included  offered 
by  Version  1.0  with  the  exception  of  the  help  menus.  To  find  out 
more  about  the  assigner,  force  level,  or  scenario  system  menus, 
turn  to  Sections  6,  8  and  9. 


Menu  is  TOP  *  ALIAS  OOMIAND  SYSlfM  *  Scenario  is  EEMO 

pop  to  previous  msiu  1  /  pop  to  top  menu 

&  reprint  with  currant  values  i  {-t  build  ccnnand  file 

}  aid  ccninand  file  building  I  {  use  ccomand  file 

?  use  help  processor  I 


TOP  LEVEL  PLUS  CDMMAND  MENJ 
CUSTOMIZE  USER.  EMVIRCMMEMT 
GAIL  NQM-i^IAS  PBOCESSQRS 
DATA  BASE  UPDATING  SXSIEM 
HANUi^  ASSIGNMENT  EDITSR 
FORCU  level  report  GQIERATOR 
SCENARIO  (BOICE/IAKEZJP  S^S^ 

OOMIAND  :Q 

Sure  you  want  to  terminate  your  ALIAS 
END  OF  PROGRAM 


( 

'X'* 

'.N'. 


session?Y 


1. 

2. 

3. 

4. 

5. 

6. 


5.0 


ALIAS  is  a  "data  driven"  software  system,  meaning  that  much 
of  its  capability  comes  from  the  way  in  which  its  data  is  stored 
and  manipulated,  rather  than  from  the  internal  logic  of  its 
computer  programs.  This  makes  it  flexible,  since  data  is  easy  to 
change  as  new  needs  arise,  while  programs  are  hard  to  change. 

Consider  the  construction  schedules  for  the  ships  of  a  POM 
projection.  Often  these  will  be  generated  by  a  run  of  the  as- 
signer,  using  standard  time  intervals  between  milestone  dates  for 
each  type  of  ship.  Do  the  schedules  just  have  the  year  of  award 
and  these  planned  intervals?  Mo,  they  have  explicit  milestone 
dates,  as  computed  by  the  assigner  from  the  planning  factors 
(intervals).  This  makes  than  usable  by  processors  other  than  the 
assigner,  especially  since  they  are  identical  in  format  to  the 
schedules  for  jobs  currently  underway  and  for  historical  jobs. 

And  if  you  do  not  like  the  milestones  the  assigner  generates  for 
any  given  ship,  you  are  free  to  change  them  and  make  your  changes 
stick. 

Data  useful  for  more  than  one  purpose  is  always  stored  in 
the  data  base,  and  in  low-level,  detailed  formats  which  allow  you 
to  fine-tune.  This  standardization  ensures  that  any  changes  you 
make  in  the  underlying  data  will  be  reflected  in  all  the  reports 
you  produce,  not  just  one. 

Figure  5-1  diagrams  the  data  flows  involving  the  data  base. 
Most  of  the  incoming  volume  is  data  input  resulting  from  reports 
from  the  field,  while  most  of  the  output  is  in  the  form  of 
reports.  Of  crucial  importance  to  you  as  a  user,  however,  are 
the  (usually)  low-volume  changes  made  to  data  base  values  during 
the  course  of  an  analysis.  The  ability  to  make  these  changes  to 
the  picture  of  the  ship  acquisition  world  which  the  data  base 
holds  makes  it  possible  for  you  to  implement  a  wide  variety  of 
assumptions  about  the  course  of  future  events.  In  order  to  use 
this  capability,  you  must  understand  how  the  ALIAS  data  base  is 
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organized.  This  knowledge  will  also  help  you  construct 
customized  reports. 

5.1  DATA  BASE  ORGANIZATION 

ALIAS  has  a  central  data  base  and  a  number  of  peripheral 
data  bases,  as  diagrammed  in  Figure  5-2.  Die  centred  data  base 
contains  all  the  data  which  you  can  update  using  the  Data  Base 
Updating  system,  and  is  the  only  one  managed  by  the  scenario 
system.  Peripheral  data  bases  are  those  created  by  individuals 
or  teams  to  support  their  own  projects;  there  may  be  plans  to 
include  these  in  the  central  data  base  at  some  point,  or  they  may 
be  for  temporary  use.  Examples  of  periphered  data  bases  are 
NAVSHIPSO's  material  and  equipment  production  capacity  and  lead 
time  data  bases  (large  and  heavily  used),  and  the  per-unit  ship 
cost  estimate  data  base  used  in  the  sample  session  in  Section  3 
(smedl  and  temporary)  . 

Because  all  ALIAS  data  bases  are  organized  along  relational 
lines,  it  is  often  possible  to  combine  information  in  central  and 
peripheral  data  bases  to  produce  reports  (this  was  done  to  pro¬ 
duce  the  cost  report  in  the  sample  session) .  llie  distinction 
between  central  and  peripheral  data  bases  focuses  on  how  data 

gets  into  them - data  input  to  the  central  DB  must  meet  high 

standards  of  internal  consistency,  while  owners  of  peripheral  DBs 
set  their  own  standards.  The  distinction  is  less  important  for 
report  production  because  the  RELATE  commands  used  to  produce 
reports  are  capable  of  combining  data  from  a  wide  variety  of 
sources. 

Lack  of  consistency  can  cause  some  problems  for  report 
production,  however.  For  example,  if  one  data  base  uses  the  code 
"DD-SSB"  and  another  "DD  963”  for  the  same  class  of  ship,  RELATE 
will  be  unable  to  combine  their  data. 


All  ALIAS  data  bases  are  composed  of  relation^,  which  are 
RELATE  data  files.  Each  relation  requires  two  HP  3000  files,  one 
for  the  actual  data  and  one  for  indexing  (sort  ordering)  informa¬ 
tion.  13ie  first  is  named  after  the  relation  (up  to  7  characters, 
e.g.,  SHDESC) ,  while  the  second  has  a  "Q”  appended  to  its  n^une 
(e.g.,  SHOES CQ) .  To  access  a  relation  using  RELATE  you  need  only 
know  its  primary  neune. 

Each  relation  is  a  table  composed  of  rows  and  columns.  The 
columns  are  named  and  are  often  called  "fields”,  while  the  rows 
are  called  "records”  or  "tuples”.  Generally  each  field  is  meant 
to  describe  some  aspect  of  something;  thus  a  row  is  a  description 
of  one  instance  of  that  thing.  For  example,  the  SHDESC  relation 
holds  (partial)  pl^sical  descriptions  of  ship  classes.  The 
fields  are  things  like  CLASS  and  LADILTONS;  a  record  holds  the 
description  for  a  single  class. 

There  is  a  unique  key  field  set  for  each  relation.  The  set 
of  values  found  in  these  fields  in  any  given  record  will  be 
unique.  The  nature  of  the  unique  key  field  set  for  a  given  rela¬ 
tion  influences  how  queries  of  it  should  be  constructed.  Ilie 
unique  key  fields  for  the  SHDESC  relation  are  SCENARIO, CLASS, 
DATADATE  ,  ENTRY^  DATE . 

When  DATADATE  appears  in  a  key  field  set  it  means  that  more 
than  one  instance  of  the  "substantive"  subset  of  the  key  field 
values  can  be  in  the  relation  simultaneously.  In  the  SHDESC 
example  there  can  be  more  than  one  record  for  any  given  class 
(for  a  given  scenario) .  In  such  cases  you  must  structure  your 
queries  to  get  the  record  with  the  latest  data  (if  that  is  what 
you  desire) .  The  only  central  data  relation  which  does  NOT  have 
DATADATE  in  its  unique  key  field  set  is  ncjodat.proj j. 

Relations  which  hold  data  about  a  given  subject  tend  to  be 
stored  together  in  separate  HP  file  groups.  For  example,  data 


having  to  do  with  individual  ships  currently  under  construction 
is  kept  in  relations  in  the  .currj  group.  If  you  want  to  know 
about  schedules  for  such  ships,  you  should  refer  to  relation 
ncjodat. currj . 

To  fully  utilize  the  resources  of  the  data  base,  you  must 
know  what  relations  it  contains  and  what  fields  each  relation 
has.  This  will  be  the  subject  of  Section  5.3. 

5.2  DATA  BASE  ACCESS  METHODS 

There  are  four  major  ways  of  extracting  data  from  the  data 
base.  These  are  queries,  report  generation,  using  the  Data  Base 
Updating  System,  and  writing  programs.  There  is  only  one  way  of 
changing  the  contents  of  the  data  base:  the  Data  Base  Updating 
System  (see  Section  7)  . 

ALIAS  security  restricts  the  ways  in  which  you  can  use 
these  methods:  queries  and  report  generation  must  be  done 
interactively  while  running  RELATE,  and  you  may  only  run  RELATE 
when  logged  on  under  your  "R”  user  name  (e.g.,  JOHNR,  not  JOHNA) . 
You  will  not  be  allowed  to  change  any  data  base  values  when 
operating  in  this  mode. 

The  DBU  may  only  be  run  from  the  ALIAS  Command  System, 
which  in  turn  can  be  run  only  when  you  are  logged  on  under  your 
"A"  user  name.  Custom  programs  which  you  write  must  likewise  be 
run  in  your  "A"  persona. 

5.2.1  Queries 

A  query  can  be  thought  of  as  a  question  you  ask  the  data 
base  using  interactive  RELATE  commands.  It  can  range  from  "Tell 
me  the  names  of  all  the  ship  classes  the  Navy  has  built"  to  "Tell 
me  how  many  ships  are  projected  for  SCN  award  next  year  and  how 
much  each  is  projected  to  cost"  to  very  complicated  questions. 

To  make  a  query  you  must  decide  what  information  is  required, 


identify  fields  in  particular  relations  which  hold  this  informa¬ 
tion,  and  then  combine  the  relations'  contents  in  a  way  that  will 
give  you  the  desired  printed  output  on  your  terminal. 

!nie  output  is  generally  in  relational  form,  i.e.  in  a  table 
of  rows  and  columns,  but  you  can  also  obtain  summary  statistics 
about  any  given  table.  To  find  out  the  delivery  dates  of  new 
ships  projected  for  delivery  in  the  first  half  of  fiscal  1990  you 
would  give  the  following  commands  when  running  RELATE: 

DOPEN  FILE  NCJODAT.PROJJ;MOOEsSHARED 

2)  SELECT  SCENARIO,  CLASS,  HULL,  DELIVERY  BY  DELIVERY  & 

.1&)WHERE  DELIVERY>»" 10/1/1989"  AND  DELIVERY<«"3/30/1990 "& 
.2&)AND  SCENARIO- "DEMO” 

WARNING:  TEMPORARY  INDEX  WILL  BE  CREATED  TO  SATISFY  BY  CLAUSE. 

3 )  PRINT 


and  would  get  this  as  a  result: 


DELIVERY 

SCENARIO 

CLASS 

HULL 

10/30/1989 

DEMO 

SSN-688 

756 

10/31/1989 

DEMO 

CG-47 

61 

10/31/1989 

DEMO 

MSH-1 

7 

11/01/1989 

DEMO 

T- AO-1 87 

194 

11/01/1989 

DEMO 

AO-187 

191 

11/01/1989 

DEMO 

AFDM 

1 

11/02/1989 

DEMO 

MCM-1 

7 

12/15/1989 

DEMO 

AE 

3 

12/21/1989 

DEMO 

T-ACS 

8 

12/30/1989 

DEMO 

CG-47 

62 

12/31/1989 

DEMO 

SSN-688 

757 

1/02/1990 

DEMO 

MCM-1 

8 

1/30/1990 

DEMO 

MSH-1 

8 

3/01/1990 

DEMO 

DD-963 

999 

14  LINES  PRINTED. 


That  was  an  example  of  a  query  from  a  single  table.  A 
similar  one  requiring  data  from  two  tables  might  request  that  the 
standard  service  life  of  each  ship  be  given  as  well  as  its 
delivery  date: 
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4)  OPEN  FILE  SHLIFE.NISCJ;MODE-SHARED 

5)  SET  PATH  NCJODAT 

6)  SELECT  SCENARIO, CLASS, HULL, DELIVERY, SHLIFE. LIFE,  & 

.!&) SHLIFE.TIMUNT  BY  DELIVERY  & 

.2&)WHERE  DELIVERY>«" 10/ 1/1989"  AND  DELIVERY<«"3/30/1990 "& 

.3&)  AND  SCENARIO- "DEMO"  AND  SHLIFE.SCENARIO-NCJODAT. SCENARIO  & 
.4&)  AND  SHLIFE.CLASS-NCJODAT. CLASS 
WARNING:  TEMPORARY  INDEX  WILL  BE  CREATED  TO  SATISFY  BY  CLAUSE. 

7)  PRINT 


DELIVERY 

SCENARIO 

CLASS 

HULL 

LIFE 

TIMUNT 

10/30/1989 

DEMO 

SSN-688 

756 

30 

CALYR 

10/31/1989 

DEMO 

CG-47 

61 

30 

CALYR 

10/31/1989 

DEMO 

MSH-1 

7 

30 

CALYR 

11/01/1989 

DEMO 

T- AO-1 87 

194 

30 

CALYR 

11/01/1989 

DEMO 

AO-187 

191 

30 

CALYR 

11/01/1989 

DEMO 

AO-187 

191 

30 

CALYR 

11/01/1989 

DEMO 

AFDM 

1 

30 

CALYR 

11/02/1989 

DEMO 

MCM-1 

7 

30 

CALYR 

12/15/1989 

DEMO 

AE 

3 

30 

CALYR 

12/21/1989 

DEMO 

T-ACS 

8 

30 

CALYR 

12/30/1989 

DEMO 

CG-47 

62 

30 

CALYR 

12/31/1989 

DEMO 

SSN-688 

757 

30 

CALYR 

1/02/1990 

DEMO 

MCM-1 

8 

30 

CALYR 

1/30/1990 

DEMO 

MSH-1 

8 

30 

CALYR 

3/01/1990 

DEMO 

DD-963 

999 

30 

CALYR 

15  LINES  PRINTED. 


The  additional  conditions  "AND  SHLIFE. SCENARIO-SCENARIO  AND 
SHLIFE. CLASS- CLASS"  tell  RELATE  that  for  every  record  it  finds 
meeting  the  delivery  date  and  scenario  conditions  in  the  ncjodat. 
projj  relation,  it  should  find  a  record  in  the  shlife.miscj 
relation  with  matching  SCENARIO  and  CLASS  field  values.  RELATE 
effectively  glues  the  contents  of  the  two  tables  together 
side-by-side  (all  classes  were  arbitrarily  assigned  the  same 
service  lives  in  this  sample  data). 

Notice  that  this  second  query  resulted  in  a  15-line  table 
instead  of  the  14  lines  from  the  first  query;  AO-187:191  was 
printed  twice.  This  happened  because  shlife.miscj  is  one  of  the 
relations  which  has  DATADATE  Included  in  its  unique  key  field 


set.  There  were  two  records  in  shlife.miscj  for  the  AO>I87 
class#  with  two  different  DATADATE  values.  RELATE  produced  a 
result  including  the  data  from  each  such  "duplicate”  record.  To 
avoid  this  sort  of  problem#  the  following  alternative  type  of 
query  should  be  given: 


8)  SELECT  SCENARIO# CLASS# HULL# DELIVERY# SHLIFE. LIFE#  & 

.1&)  SHLIFE.TIMUNT  BY  DELIVERY  & 

.2&)WHERE  DELIVERY>»"10/1/1989"  AND  DELIVERY<»"3/30/1990 "& 

.3&)  AND  SCENARIO- "DEMO”  AND  SHLIFE. SCENARIO-NCJODAT. SCENARIO  & 
.4&)  AND  SHLIFE. CLASS-NCJODAT. CLASS  & 

.5&)  AND  SHLIFE. DATADATE-$MAX( SHLIFE. DATADATE  BY  & 

.6&)  SHLIFE. SCENARIO# SHLIFE. CLASS) 

WARNING:  TEMPORARY  INDEX  WILL  BE  CREATED  TO  SATISFY  BY  CLAUSE. 

9)  PRINT 


DELIVERY 

SCENARIO 

CLASS 

HULL 

LIFE 

TIMUNT 

10/30/1989 

DEMO 

SSN-688 

756 

30 

CALYR 

10/31/1989 

DEMO 

CG-47 

61 

30 

CALYR 

10/31/1989 

DEMO 

MSH-1 

7 

30 

CALYR 

11/01/1989 

DEMO 

T- AO-1 87 

194 

30 

CALYR 

11/01/1989 

DEMO 

AO-187 

191 

30 

CALYR 

11/01/1989 

DEMO 

AFDM 

1 

30 

CALYR 

11/02/1989 

DEMO 

MCM-1 

7 

30 

CALYR 

12/15/1989 

DEMO 

AE 

3 

30 

CALYR 

12/21/1989 

DEMO 

T-ACS 

8 

30 

CALYR 

12/30/1989 

DEMO 

CG-47 

62 

30 

CALYR 

12/31/1989 

DEMO 

SSN-688 

757 

30 

CALYR 

1/02/1990 

DEMO 

MCM-1 

8 

30 

CALYR 

1/30/1990 

DEMO 

MSH-1 

8 

30 

CALYR 

3/01/1990 

DEMO 

DD-963 

999 

30 

CALYR 

14  LINES  PRINTED. 


The  extra  condition  SHL I FE. DATADATE- SMAX( SHLIFE. DATADATE  BY 
SHLIFE. SCENARIO# SHLIFE. CLASS)  tells  RELATE  to  use  only  those 
shlife.miscj  records  which  have  the  largest  (latest)  DATADATE 
value  for  each  different  set  of  values  for  SCENARIO#  CLASS.  The 
result  is  then  as  expected.  This  condition  should  be  used  in 
queries  of  any  relation  which  includes  DATADATE  in  its  unique  key 
field  set  and  for  which  you  want  only  the  latest  data. 
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The  query  results  so  far  have  been  in  the  usual  relational 
form;  they  might  have  been  obtained  just  by  printing  the  contents 
of  an  existing  relation,  had  one  existed  which  held  the  exact 
data  desired.  Suppose  that  only  the  number  of  ships  to  be 
delivered  in  the  first  heilf  of  1990  was  desired,  not  data  about 
each  one.  In  the  examples  above  it  is  easily  seen  that  the 
number  is  ”14”,  but  if  you  were  making  a  query  where  the  expected 
answer  was  more  like  ”2000”  you  might  not  want  to  watch  2000 
lines  of  output  scroll  across  your  terminal  just  to  find  out  how 
many  there  were.  To  get  the  count  only,  give  a  query  similar  to 
the  following  one: 

8)  SELECT  NUM=$COUNT(HULL  WHERE  SCENARIO ”DEMO”  AND  & 
.l&)DELIVERy>  =  ”10/l/1989”  AND  DELIVERY<  =  ”3/3  0/1990”  ) 

9)  PRINT 

NUM 

14 

1  LINE  PRINTED. 

Notice  that  the  conditions  on  the  count  must  go  jnside  the 
parentheses  of  the  $COUNT  aggregate. 

To  learn  more  about  how  to  construct  queries  using  RELATE, 
see  especially  the  sections  on  the  SELECT  and  PRINT  commands  in 
the  RELATE  Reference  Manual. 

5 .2 .2  Reports 

The  sample  queries  of  the  last  section  produced  output  that 
was  fairly  rough-and-ready.  Although  you  have  some  control  over 
the  order  and  placement  of  the  columns  of  output  produced  by  the 
PRINT  statement  through  the  use  of  ”switches”  (see  the  RELATE 
manual) ,  more  sophisticated  formatting  requires  the  use  of  the 
CREATE  report  generator.  CREATE  is  part  of  the  RELATE  software 
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package  and  is  accessed  from  RELATE  by  giving  the  REPORT  command. 

CREATE  does  not  enhance  your  ability  to  make  queries  at  all - you 

must  set  up  the  query  using  OPEN  FILE  and/or  SELECT  statements 

prior  to  giving  the  REPORT  command - but  does  greatly  increase 

your  control  over  the  appearance  of  the  output. 

Suppose  you  wanted  to  know  delivery  dates  for  cruisers  and 
guided  missile  destroyers  being  delivered  in  the  first  half  of 
fiscal  1993,  and  that  you  wanted  the  dates  grouped  by  ship  class 
in  a  simple  but  presentable  fashion.  The  following  commands 
might  be  used  to  do  your  bidding: 

DOPEN  FILE  NCJODAT.PROJJ;MODE=SHARED 

2)  SELECT  SCENARIO,  CLASS,  HULL,  DELIVERY  BY  CLASS,  DELIVERY  & 

.1&)  WHERE  SCENARIO* "DEMO"  AND  DELIVERY>="10/1/1992 "  AND  & 

.2&)  DELIVERY<=" 3/30/1993" 

WARNING:  TEMPORARY  INDEX  WILL  BE  CREATED  TO  SATISFY  BY  CLAUSE. 

3 )  REPORT 

1>PAGE  HEADING- ("Scenario  " ;TAB-40) ,( SCENARIO; TAB-49) , & 

.  1&> 

.24>("AAW  DELIVERIES  BY  CLASS,  FIRST  HALF  1993 " ;NEWLINE=2 ; 

.3S>  JUSTIFY- CENTER) 

2>FIELDS=( SCENARIO ;NOPRINT) , (CLASS; NOPRINT; BREAK-10) ,& 
.1S>(HULL;TAB-10;NOHEADING) , (DELIVERY;TAB=20 ;NOHEADING) 

3>GROUP  HEADING  10-(NEWLINE-3) , (CLASS;TAB-18) ,& 

.1&>  ( "DELIVERIES ";TAB-+1) , (NEWLINE-2) , ( "HULL "; TAB-17 ;DNDERL) ,& 
.2&>  ("DATE"; TAB-27; UNDERLINE) 

4>GO 


with  the  result: 

Scenario  DEMO 
12/12/84 

AAW  DELIVERIES  BY  CLASS,  FIRST  HALF  1993 


CG 

DELIVERIES 

HULL 

DATE 

60 

01/16/1993 

61 

03/28/1993 
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DDG  DELIVERIES 


HULL 

DATE 

57 

12/20/1992 

58 

2/28/1993 

59 

3/15/1993 

Note  particularly  that  output  can  be  grouped  according  to 
the  changing  values  of  one  or  more  fields  by  using  the  BREAK- 
option  in  the  FIELD  command  in  combination  with  the  GROUP  HEADING 
and  GROUP  FOOTING  commands.  In  the  example  a  new  group  was 
produced  every  time  CREATE  came  to  a  new  class  name;  the  name  of 
the  class  was  placed  in  the  group  heading  instead  of  in  a  column. 

Also  note  that  CREATE  commands  can  be  placed  in  an  editor- 
type  file  along  with  OPEN  FILE  and  SELECT  statements.  In  this 
form  the  report  the  statements  produce  can  be  run  over  and  over 
again  from  RELATE  using  the  EXECUTE  command.  The  work  of  setting 
up  and  entering  report  commands  thus  needs  to  be  done  only  once. 

See  the  CREATE  manual  for  more  information  about  how  to 
generate  formatted  reports. 

5.2.3 

A  limited  amount  of  querying  can  be  done  using  the  Search 
command  of  the  Data  Base  Updating  system  (DBU)  .  You  can  type  in 
field  values  which  target  records  must  match,  and  the  DBU  will 
attempt  to  find  such  records  for  you  by  constructing  a  custom 
SELECT  statement.  You  can  then  print  the  result  using  the  P 
command. 

However,  you  are  generally  limited  to  retrieval  of  data 
from  a  single  relation,  cannot  put  on  restrictions  such  as  the 
range  of  valid  dates  specified  in  the  above  queries,  and  can  only 
look  at  the  output  one  record  at  a  time  on-screen.  This  method 
is  thus  most  useful  when  your  target  is  one  or  a  few  records 
whose  values  you  want  to  change  rather  than  just  look  at. 
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See  Section  7  for  more  Information  about  the  DBU 


5.2.4 

If  you  are  a  programmer,  you  can  construct  even  more 
sophisticated  queries  than  RELATE  is  capable  of  by  writing  pro¬ 
grams  which  access  the  data  base  through  RELATE' s  Host  Language 
Interface.  Before  using  one  of  the  more  traditional  languages 
such  as  FORTRAN  or  COBOL,  see  if  your  task  can  be  done  using  the 
BUILDER  screen  language  interpreter  which  was  used  to  implement 

the  DBU - if  so,  the  time  you  will  need  to  spend  to  implement 

your  program  will  be  reduced  by  a  large  factor. 

See  the  ALIAS  Maintenance  Guide  for  more  information  about 
creating  programs  in  the  ALIAS  environment. 

5.3  STRUCTURE  OF  THE  DATA  BASE 

This  section  will  describe  the  relations  and  fields  of  the 
central  ALIAS  data  base  in  some  detail.  It  is  meant  as  a  ref¬ 
erence  for  your  use  in  constructing  queries.  Most  of  the  in¬ 
formation  presented  here  can  also  be  found  in  the  ALIAS  data 
dictionary,  which  always  contains  the  most  up-to-date  description 
of  the  data  base  structure. 

5.3.1 

The  ALIAS  data  dictionary  is  a  data  base  in  its  own  right. 
It  consists  of  several  relations  stored  in  the  .db  group  (e.g., 
filinfo.db).  The  data  dictionary  serves  three  purposes: 

1)  It  is  a  reference  which  can  be  used  to  discover  how  the 
data  base  is  set  up. 

2)  The  DBU  consults  it  for  rules  which  your  data  base 
updates  must  conform  to. 

3)  It  is  used  as  the  basis  for  creation  of  the  central  data 

base  relations - a  special  program  creates  the  relations 

from  their  data  dictionary  structural  descriptions, 
ensuring  that  the  data  dictionary  and  the  actual  data 
base  agree  with  one  another. 
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Table  5-1  lists  the  relations  in  the  data  dictionary  and 
describes  their  purpose.  Table  5-2  is  an  annotated  list  of  the 
fields  in  selected  dictionary  relations. 

5.3.2  .Tbifi-Pata.£^.£ 

Table  5-3  is  an  annotated  listing  of  the  groups  that 
centrtions  in  these  groups  are  necessarily  in  the  central  data 
base).  Table  5-4  is  an  annotated  listing  of  relations  in  each 
group.  Table  5-5  lists  the  fields  in  each  relation,  while  Table 
5-6  describes  the  purpose  of  each  field.  Tables  5-5  and  5-6  may 
be  reproduced  from  the  contents  of  the  fldfile.db  and  fldesc.db 
relations  whenever  you  desire. 

Note  that  any  field  which  appears  with  the  same  name  in 
multiple  relations  will  always  have  the  same  data  format, 
enabling  you  to  reliably  join  data  from  several  relations. 
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Table  5-1.  Annotated  List  of  Data  Dictionary  Relations 


RELATION 

DBFLDS 

PILDESC 

FILINDX 

FILINFO 

FILJOIN 

FILPRIV 

FILSCRN 

FLDESC 

FLDFILE 

FLDUSER 

REPTEX 

SCRFLDS 

SCRPRIV 


PURPOSE 


A  list  of  all  the  fields  in  the  central  data  base^ 
including  information  such  as  data  type  ( integer ^ 
alpha#  etc.)  and  size.  Though  a  field  may  appear  in 
several  relations,  it  will  always  conform  to  the 
standards  set  here. 

Textual  descriptions  of  the  purpose  of  each  data 
relation. 

Contains  the  permanent  indexes  which  exist  for  each 
data  relation.  Used  by  the  makfile.dba  relation 
creation  processor  to  create  the  indexes  at  file 
creation  time. 

A  list  of  the  relations  in  the  central  data  base, 
along  with  brief  descriptions  of  purpose  and 
parameters  used  by  various  ALIAS  processors. 

Data  base  integrity  maintenance  rules;  used  by  the 
DBU  to  validate  updates. 

Data  base  security  privilege  information.  Lists 
relations  and  which  users  may  perform  which  DBU 
functions  on  them.  These  security  specifications 
apply  only  to  DBU  operations. 

A  cross  reference  describing  which  DBU  screens  serve 
each  data  relation. 

Textual  descriptions  of  the  purpose  of  each  data  base 
field. 

A  cross  reference  describing  which  fields  are  in  each 
data  relation.  Used  by  the  makfile.dba  relation 
creation  processor  to  determine  file  structure  at 
creation  time. 

A  list  of  the  ALIAS  processors  which  use  each  field 
in  each  file.  Useful  for  determination  of  the 
magnitude  of  impact  of  changes  to  a  given  field  in  a 
given  relation. 

A  list  of  available  report  generators. 

A  list  of  the  fields  appearing  on  each  DBU  screen, 
including  cross  references  between  screen  variable 
names  and  associated  relation  field  names. 

DBU  security  privilege  information.  Lists  DBU 
screens  and  which  users  may  perform  which  functions 
when  using  them. 
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Table  5-1.  Annotated  List  of  Data  Dictionary  Relations 


RELATION 


PURPOSE 


Table  5-2.  Annotated  List  of  Data  Dictionary  Fields 


RELATION 

DBFLDS 


FILINDX 


FILINFO 


FIELD  PURPOSE 


FIELDNAME 

DATATYPE 

MAXVALUE 


FORMATS PEC 


UNITYPE 


PRINTLEN 


LEGLFILE 


FILE 

GROUP 

INUM 


INDEX 


FILE 

GROUP 

FAMILY 

DOMAIN 

CODERESP 

RELNUM 

SCENSET 


Name  of  the  field  the  record  describes. 

Data  type  of  the  field. 

Gives  the  maximum  size  of  the  data  value  the 
field  can  hold.  The  biggest  number  for 
numeric  fieldsr  number  of  characters  for 
alphanumeric. 

The  special  conditions  section  of  the  field 
creation  syntax  used  during  creation  of 
files  the  field  is  in. 

Units  the  field  is  expressed  in.  This  is  ar 
important  reference  for  understanding  of  the 
contents  of  some  numeric  fields. 

Field  width  specification  for  file  creation 
statements.  Must  agree  with  MAXVALUE  for 
alphanumeric  fields. 

Blank  for  fields  whose  acceptable  values  are 
NOT  specified  by  a  list  in  the  legal  values 
reference  library  (set  of  relations  in  the 
.legals  group).  For  legals-type  fields, 
name  of  the  .legals  relation  holding  the 
appropriate  list. 

Name  of  the  relation  the  index  is  on. 

Group  the  relation  resides  in. 

Number  the  index  has  (determines  the  order 
in  which  indexes  are  created  and  thus  which 
index  is  picked  by,  e.g.,  SET  INDEX  1. 
Specification  of  the  fields  in  the  index  in 
CREATE  INDEX  syntax,  including  the  UNARY 
specification  if  any. 

Name  of  the  relation  the  record  describes. 
Group  the  relation  resides  in. 

Expanded  phrase  describing  the  data  group 
the  relation  belongs  to. 

PUBLIC  or  PRIVATE. 

NAVSEA/NAVSHIPSO  code  responsible  for  data 
update. 

ID  number  of  the  relation.  An  obsolete 
field  no  longer  used. 

Name  of  the  data  group  the  relation  belongs 
to  for  scenario  purposes.  Generally  the 
name  of  the  HP  file  group  the  relation  is 
in,  but  "SYSTEM"  for  relations  which  are  not 
scenario  dependent  (e.g.  data  dictionary 
relations  or  .legals  relations) ,  and 
"PARAMS"  for  relations  forming  the  special 
command  system  data  base  created  by  program 


Table  5-2.  Annotated  List  of  Data  Dictionary  Fields 


RELATION 


FILJOIN 


FIELD  PURPOSE 


SCENUN 


SCRSET 


SCRNUM 


SCRPROC 


SCRINDX 

QDESCRIP 


Scenario  system  ID  number  of  the  relation. 
Determines  the  storage  column  for  the 
relaticn'e  scenario  field  values  in  the 
table  which  cross  references  overall 
scenario  name  to  key  values  (table  stored  in 
relsnl.sysrwr  readable  only  by  ALIAS) .  MUST 
NOT  BE  CHANGED  ONCE  DETERMINED  FOR  A  GIVEN 
RELATION.  Must  be  unique  for  each  relation. 
Name  of  the  data  group  the  relation  belongs 
to  for  DBU  purposes.  Must  be  "LEGALS"  for 
.legals  relations;  the  DBU  uses  the  value  of 
this  field  to  determine  which  relations  to 
open  as  the  legal  values  reference  library. 
DBU  ID  number  of  the  relation.  Determines 
the  storage  location  in  the  DBU  file 
management  system's  extra  data  segment  for 
the  relation's  actual  partition.  Must  be 
unique.  . 

ID  of  the  RELATE  son  process  that  the  DBU 
will  create  the  relation's  actual  partition 
in.  Relations  may  be  redistributed  among 
more  processes  if  overflows  occur  as  ALIAS 
is  expanded. 

Number  of  the  index  which  should  be  SET  to 
when  the  relation  is  opened  by  the  DBU. 

A  one-line  description  of  the  purpose  of  the 
relation. 


SRCFILE 

SRCGROUP 

SRCFIELD 


TGTFILE 

TGTGROUP 

TGTFIELD 


FLEV 


JOINTYPE 


Name  of  a  relation  and  field  within  the 
relation  which  is  to  be  half  of  one  clause 
in  a  join  condition  which  must  be  satisfied 
before  an  addition  or  modification  to  the 
SRC  relation  can  be  made. 

Name  of  a  relation  and  field  within  it 
which  is  the  other  half  of  this  join 
condition  clause.  The  clause  will  take  the 
form  AND  SRCFILE. SRCFIELD«TGTFILE,TGTFI ELD, 
anc  there  will  be  as  many  clauses  in  the 
condition  as  there  are  records  in  filjoin.db 
with  identical  sets  of  values  for 
srcf ile,srcgroup, tgtf ile,  and  tgtgroup. 
Numeric  field  whose  value  determines  the 
order  in  which  clauses  appear  in  the 
condition. 

One  of  REQUIRED  (data  update  can't  be  made 
if  a  SELECT  made  with  the  condition  as  its 
WHERE  clause  finds  no  records) ,  RECOMMENDED 
(a  warning  is  issued  by  the  DBU  if  the 
SELECT  finds  no  records) ,  or  IN.CNE:Ar 
IN_ONE:Br  etc.  If  the  condition  fails  for 
the  two  relations  forming  IN_ONE:Ar  then  the 


Table  5-2.  Annotated  List  of  Data  Dictionary  Fields 


RELATION 


FILPRIV 


FILSCRN 


FLDFILE 


FLDOSER 


SCRFLDS 


FIELD  PURPOSE 


JOINMSG 

DATANAME 


FILE 

GROUP 

USERNAME 


READ 

ADD 

DELETE 

UPDATE 

MODIFY 

FILE 

GROUP 

SCREEN 


FILE 

GROUP 

FIELDNAME 

FLDNUM 


CODERESP 

PRIMSOURCE 

SECSOURCE 

FILE 

GROUP 

FIELDNAME 

USERNAME 


USERTYPE 


SCREEN 

SCRVAR 


DBU  moves  on  to  try  IN_ONE:Br  and  sc  on. 

Text  placed  in  DBU's  warning  or  failure 
message  regarding  update  request. 

Text  placed  in  DBU's  verification  message 
during  subsidiary  data  deletion;  should 
describle  the  kind  of  data  in  the  SRC 
relation. 

Name  of  the  relation  the  security 
specification  applies  to. 

Name  of  the  group  the  relation  is  stored  in. 
Name  of  the  user  the  specification  applies 
to.  Limit  of  one  specification  per 
relation-user  combination. 

"Y”  if  user  can  read  the  relation's 
contents. 

"Y”  if  user  can  add  records  to  the  relation. 
"Y"  if  user  can  delete  records. 

”Y”  if  user  can  update  records. 

"Y"  if  user  can  modify  records. 

Name  of  the  relation  the  screen  serves. 

Group  the  relation  is  stored  in. 

Name  of  the  DBU  screen  used  to  update  the 
relation. 

Name  of  the  relation  the  field  appears  in. 
Name  of  the  group  the  relation  is  stored  in. 
Name  of  a  field  found  in  the  relation. 

Column  number  in  which  the  field  appears. 
SCENARIO  must  always  have  a  FLDNUM  value  of 
1. 

NAVSEA/NAVSHIPSO  code  responsible  for  update 
of  the  field's  data. 

Primary  source  of  the  field's  data. 

Secondary  source  for  the  field's  data. 

Name  of  the  relation  the  field  is  in. 

Group  the  relation  is  stored  in. 

Name  of  a  field  in  the  relation. 

Name  of  the  ALIAS  module  or  report  generator 
which  makes  use  of  and/or  changes  values  of 
the  field. 

Nature  of  the  user - program,  screen,  or 

report  generator. 

Name  of  the  DBU  screen  the  field  appears  in. 
Name  of  the  screen  variable  serving  the 
field. 
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Table  5-2, 


RELATION  FIELD 


FIELDNAME 

FILE 

GROUP 

FLDTYPE 


SCRPRIV  SCREEN 


Annotated  List  of  Data  Dictionary  Fields 


PURPOSE 


Name  of  the  field  in  its  relation. 

Name  of  the  relation. 

Name  of  the  group  the  relation  is  in. 

Role  the  field  plays  in  the  relation  and  on 

the  screen - key  field  (i.e.  part  of  the 

relation's  unique  key  field  set)  r  ordinary 
data  field,  or  legals  field  (one  whose  value 
must  be  on  an  approved  list  stored  in 
. legals) . 

Name  of  the  DBU  screen  the  privileges  are 
for. 

Name  of  the  user  the  privileges  are  for. 

"Y"  if  user  is  allowed  to  use  the  given 
screen. 


USERNAME 

SEEIT 


Table  5-3.  Annotated  List  of  Central  Data  Base  Groups 


GROUP 

CURRJ 

DB 

DESCJ 

HISTJ 

LEGALS 

MISCJ 

HNUREL 

MAKMENU 

PROJJ 


PURPOSE 


Current  SCN  and  repair  job  data,  where  "current” 
means  those  appropriated  but  not  yet  delivered. 

Data  dictionary  relations. 

Projected  job  description  data  (planning  factors) . 

Historical  SCN  and  repair  job  data,  where 
"historical”  means  those  already  delivered. 

All  relations  comprising  the  legal  values  reference 
library. 

Miscellaneous  information,  primarily  ship-class  level 
data  (physical  descriptions,  service  lives) . 

Repository  for  the  relations  which  hold  Command 
System  parameters  and  lists.  These  data  are 
scenario-dependent  and  managed  by  the  DBU. 

Projected  SCN  and  repair  job  data,  i.e.  for  those 
jobs  not  yet  appropriated. 


YARDS 


Shipyard  data 


Table  S'S.  List  of  Field  Appearing  in  Each  Relation 


NCJODAT 

NCJOCOM 

NCJOCOM 

NCJODAT 

NCJOCOM 

STRT103 

DEACT 

DEACOM 

SHCOMT 

SHLIFE 

SHDESC 

YARDIB 

REJOCOM 

REJODAT 

REJOCOM 

REJOCOM 

NCJDAT 

YARDCOM 

NCJDCOM 

NCJODAT 

REJODAT 

REJODAT 

NCJODAT 

NCJOCOM 

NCJOCOM 

NCJODAT 

NCJOCOM 

DEACT 

DEACOM 

SHCOMT 

SHLIFE 

SHDESC 

YARDID 

REJOCOM 

REJODAT 

REJOCOM 

REJOCOM 

NCJDAT 

YARDCOM 

NCJDCOM 

NCJODAT 

REJODAT 

REJODAT 

NCJODAT 

NCJOCOM 

NCJOCOM 

NCJODAT 

NCJOCOM 


HISTJ 

SCENARIO 

HISTJ 

SCENARIO 

CDRRJ 

SCENARIO 

PROJJ 

SCENARIO 

PROJJ 

SCENARIO 

DB 

DDMMY 

MISCJ 

SCENARIO 

MISCJ 

SCENARIO 

MISCJ 

SCENARIO 

MISCJ 

SCENARIO 

MISCJ 

SCENARIO 

YARDS 

SCENARIO 

CURRJ 

SCENARIO 

PROJJ 

SCENARIO 

PROJJ 

SCENARIO 

HISTJ 

SCENARIO 

DESCJ 

SCENARIO 

YARDS 

SCENARIO 

DESCJ 

SCENARIO 

CDRRJ 

SCENARIO 

HISTJ 

SCENARIO 

CDRRJ 

SCENARIO 

HISTJ 

CLASS 

HISTJ 

CLASS 

CDRRJ 

CLASS 

PROJJ 

CLASS 

PROJJ 

CLASS 

MISCJ 

CLASS 

MISCJ 

CLASS 

MISCJ 

CLASS 

MISCJ 

CLASS 

MISCJ 

CLASS 

YARDS 

YARD 

CDRRJ 

CLASS 

PROJJ 

CLASS 

PROJJ 

CLASS 

HISTJ 

CLASS 

DESCJ 

CLASS 

YARDS 

YARD 

DESCJ 

CLASS 

CDRRJ 

CLASS 

HISTJ 

CLASS 

CDRRJ 

CLASS 

HISTJ 

HDLL 

HISTJ 

HULL 

CDRRJ 

HULL 

PROJJ 

HULL 

PROJJ 

HULL 

Table  5-5.  List  of  Field  Appearing  in  Each  Relation 


DEACT 

MISCJ 

HULL 

DEACON 

MISCJ 

HULL 

SHCOMT 

MISCJ 

BULL 

SHLIFE 

MISCJ 

LIFE 

SHDESC 

MISCJ 

PRNTNAME 

YARDID 

YARDS 

YARDNAME 

REJOCOM 

CDRRJ 

HULL 

REJODAT 

PROJJ 

HULL 

REJOCOM 

PROJJ 

HULL 

REJOCOM 

HISTJ 

HULL 

NCJDAT 

DESCJ 

NCJOBT 

YARDCOM 

YARDS 

DATADATE 

NCJDCOM 

DESCJ 

NCJOBT 

NCJODAT 

CURRJ 

HULL 

REJODAT 

HISTJ 

HULL 

REJODAT 

CURRJ 

HULL 

NCJODAT 

HISTJ  ■ 

COMNUM 

NCJOCOM 

HISTJ 

COMNUM 

NCJOCOM 

CURRJ 

COMNUM 

NCJODAT 

PROJJ 

COMNUM 

NCJOCOM 

PROJJ 

COMNUM 

DEACT 

MISCJ 

COMNUM 

DEACON 

MISCJ 

COMNUM 

SHCOMT 

MISCJ 

DATADATE 

SHLIFE 

MISCJ 

TIMDNT 

SHDESC 

MISCJ 

HULL 

YARDID 

YARDS 

PARENT 

REJOCOM 

CURRJ 

JOBID 

REJODAT 

PROJJ 

JOB  ID 

REJOCOM 

PROJJ 

JOBID 

REJOCOM 

HISTJ 

JOBID 

NCJDAT 

DESCJ 

YARD 

YARDCOM 

YARDS 

ENTRYDATE 

NCJDCOM 

DESCJ 

YARD 

NCJODAT 

CDRRJ 

COMNUM 

REJODAT 

HISTJ 

JOBID 

REJODAT 

CDRRJ 

JOBID 

NCJOCOM 

HISTJ 

DATADATE 

NCJOCOM 

CURRJ 

DATADATE 

NCJOCOM 

PROJJ 

DATADATE 

DEACOM 

MISCJ 

DATADATE 

DEACT 

MISCJ 

DISPOSN 

SHCOMT 

MISCJ 

ENTRYDATE 

SHLIFE 

MISCJ 

DATADATE 

SHDESC 

MISCJ 

CUSTOMER 

YARDID 

YARDS 

ADDRESS 

REJOCOM 

CDRRJ 

DATADATE 

REJOCOM 

PROJJ 

DATADATE 

REJOCOM 

HISTJ 

DATADATE 

NCJDAT 

DESCJ 

JSTYP 
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Table  5-5.  List  of  Field  Appearing  in  Each  Relation 


NCJODAT 

HISTJ 

YARD 

NCJODAT 

PROJJ 

YARD 

REJODAT 

PROJJ 

YARD 

YARDCOM 

YARDS 

LNUM 

NCJDCOM 

DESCJ 

JSTYP 

NCJODAT 

CURRJ 

YARD 

REJODAT 

HISTJ 

REJOBT 

REJODAT 

CURRJ 

REJOBT 

NCJODAT 

HISTJ 

NCJOBT 

NCJOCOM 

HISTJ 

ENTRYDATE 

NCJOCOM 

CURRJ 

ENTRYDATE 

NCJODAT 

PROJJ 

NCJOBT 

NCJOCOM 

PROJJ 

ENTRYDATE 

DEACOM 

MISCJ 

ENTRYDATE 

DEACT 

KISCJ 

DEACT 

SHCOMT 

MISCJ 

LNUM 

SHLIFE 

MISCJ 

ENTRYDATE 

SHDESC 

MISCJ 

LENGTHUL 

YARDID 

YARDS 

STATE 

REJOCOM 

CURRJ 

ENTRYDATE 

REJODAT 

PROJJ 

REJOBT 

REJOCOM 

PROJJ 

ENTRYDATE 

REJOCOM 

HISTJ 

ENTRYDATE 

NCJDAT 

DESCJ 

COMNUM 

YARDCOM 

YARDS 

COMMENT 

NCJDCOM 

DESCJ 

DATADATE 

NCJODAT 

CURRJ 

NCJOBT 

REJODAT 

HISTJ 

YARD 

REJODAT 

CURRJ 

YARD 

NCJODAT 

HISTJ 

JSTYP 

NCJOCOM 

HISTJ 

LNUM 

NCJOCOM 

CURRJ 

LNUM 

NCJODAT 

PROJJ 

JSTYP 

NCJOCOM 

PROJJ 

LNUM 

DEACT 

MISCJ 

DATADATE 

DEACOM 

MISCJ 

LNUM 

SHCOMT 

MISCJ 

COMMENT 

SHLIFE 

MISCJ 

ENTRYEl 

SHDESC 

MISCJ 

LENGTHQA 

YARDID 

YARDS 

FSCM 

REJOCOM 

CURRJ 

LNUM 

REJODAT 

PROJJ 

JSTYP 

REJOCOM 

PROJJ 

LNUM 

REJOCOM 

HISTJ 

LNUM 

NCJDAT 

DESCJ 

CMETHD 

YARDCOM 

YARDS 

ENTRYILl 

NCJDCOM 

DESCJ 

ENTRYDATE 

NCJODAT 

CURRJ 

JSTYP 

REJODAT 

HISTJ 

JSTYP 

REJODAT 

CURRJ 

JSTYP 
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Table  5-5.  List  of  Field  Appearing  in  Each  Relation 


NCJODAT 

HISTJ 

CDSTOMER 

NCJOCOM 

HISTJ 

COMMENT 

NCJOCOM 

CDRRJ 

COMMENT 

NCJODAT 

PRCJJ 

CDSTOMER 

NCJOCOM 

PROJJ 

COMMENT 

DEACT 

MISCJ 

DATETYPE 

DEACOM 

MISCJ 

COMMENT 

SHCOMT 

MISCJ 

ENTRYEX 

SHDESC 

MISCJ 

BEAMI2L 

YARDID 

YARDS 

SMSA 

REJOCOM 

CURRJ 

COMMENT 

REJODAT 

PROJJ 

CDSTOMER 

REJOCOM 

PROJJ 

COMMENT 

REJOCOM 

HISTJ 

COMMENT 

NCJDAT 

DESCJ 

CDSTOMER 

NCJDCOM 

DESCJ 

ENITiYSl 

NCJODAT 

CDRRJ 

CDSTOMER 

REJODAT 

HISTJ 

CDSTOMER 

REJODAT 

CDRRJ 

CDSTOMER 

NCJODAT 

HISTJ 

SHIPNAME 

NCJOCOM 

HISTJ 

ENTRYEX 

NCJOCOM 

CDRRJ 

ENTRYBY 

NCJODAT 

PROJJ 

SHIPNAME 

NCJOCOM 

PROJJ 

ENTRYBX 

DEACT 

MISCJ 

DATASODRCE 

DEACOM 

MISCJ 

ENTRYfiX 

SHDESC 

MISCJ 

beanqa 

YARDID 

YARDS 

CODE071 

REJOCOM 

CDRRJ 

ENTRYBY 

REJODAT 

PROJJ 

APPROP 

REJOCOM 

PROJJ 

ENTRYEX 

REJOCOM 

HISTJ 

ENTRYBY 

NCJDCOM 

DESCJ 

COMMENT 

NCJODAT 

CDRRJ 

SHIPNAME 

REJODAT 

HISTJ 

APPROP 

REJODAT 

CDRRJ 

APPROP 

NCJDAT 

DESCJ 

COMPLEXGRP 

NCJODAT 

HISTJ 

CMETHD 

NCJODAT 

PRCJJ 

CHETHD 

DEACT 

MISCJ 

ENTRYfiX 

SHDESC 

MISCJ 

LADNHITE 

YARDID 

YARDS 

SDPSHIP 

REJODAT 

PROJJ 

AWARD 

NCJDAT 

DESCJ 

DEPLTAWDAY 

NCJOCOM 

HISTJ 

DATETYPE 

NCJDCOM 

DESCJ 

LITDK 

NCJOCOM 

CDRRJ 

DATETYPE 

NCJODAT 

CDRRJ 

CMETHD 

REJOCOM 

HISTJ 

DATETYPE 

REJOCOM 

CDRRJ 

DATETYPE 
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Table  5-5.  List  of  Field  Appearing  in  Each  Relation 


REJODAT 

HISTJ 

AWARD 

REJODAT 

CURRJ 

AWARD 

NCJODAT 

HISTJ 

APPROP 

NCJODAT 

PROJJ 

APPROP 

DEACT 

MISCJ 

ENTRYDATE 

SHDESC 

MISCJ 

LITEHITE 

YARDID 

YARDS 

HOME  PORT 

REJODAT 

PROJJ 

ARRIV 

NCJDAT 

DESCJ 

DAYSADDED 

NCJODAT 

CURRJ 

APPROP 

REJODAT 

HISTJ 

ARRIV 

REJODAT 

CURRJ 

ARRIV 

NCJODAT 

HISTJ 

AWARD 

NCJODAT 

PROJJ 

AWARD 

SHDESC 

MISCJ 

FULLHITE 

YARDID 

YARDS 

WATERWAY 

REJODAT 

PROJJ 

START 

NCJDAT 

DESCJ 

APPRCPAWD 

NCJODAT 

CURRJ 

AWARD 

REJODAT 

HISTJ 

START 

REJODAT 

CURRJ 

START 

NCJODAT 

HISTJ 

START 

NCJODAT 

PROJJ 

START 

SHDESC 

MISCJ 

LAUNPRAEI 

YARDID 

YARDS 

OCEAN 

REJODAT 

PROJJ 

DRYDOCK 

NCJDAT 

DESCJ 

AWDST 

NCJODAT 

CURRJ 

START 

REJODAT 

HISTJ 

DRYDOCK 

REJODAT 

CURRJ 

DRYDOCK 

NCJODAT 

HISTJ 

KEEL 

NCJODAT 

PROJJ 

KEEL 

SHDESC 

MISCJ 

LITEDRAFT 

YARDID 

YARDS 

TOTACRES 

REJODAT 

PROJJ 

LAUNCH 

NCJDAT 

DESCJ 

STBL 

NCJODAT 

CURRJ 

KEEL 

REJODAT 

HISTJ 

LAUNCH 

REJODAT 

CURRJ 

LAUNCH 

NCJODAT 

HISTJ 

LAUNCH 

NCJODAT 

PROJJ 

LAUNCH 

SHDESC 

MISCJ 

FULLDRAFT 

YARDID 

YARDS 

DEVACRES 

REJODAT 

PROJJ 

DELIVERY 

NCJDAT 

DESCJ 

KLM 

NCJODAT 

CURRJ 

LAUNCH 

REJODAT 

HISTJ 

DELIVERY 

REJODAT 

CURRJ 

DELIVERY 

NCJODAT 

HISTJ 

DELIVERY 

NCJODAT 

PROJJ 

DELIVERY 
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Table  5-5,  List  of  Field  Appearing  in  Each  Relation 


tv 


SHDESC 

MISCJ 

LADNTQNS 

YAROID 

YARDS 

USEDACRES 

REJODAT 

PROJJ 

DAYS ADDED 

NCJDAT 

DESCJ 

LNQL 

NCJODAT 

CDRRJ 

DELIVERY 

REJODAT 

HISTJ 

DAYSADDED 

REJODAT 

CURRJ 

DAYSADDED 

NCJODAT 

HISTJ 

COMMISSION 

NCJODAT 

PROJJ 

COMMISSION 

SHDESC 

MISCJ 

LITETQNS 

YARDID 

YARDS 

CHWIDTH 

REJODAT 

PROJJ 

ASNORDER 

NCJDAT 

DESCJ 

DLCOM 

NCJODAT 

CURRJ 

COMMISS ION 

REJODAT 

HISTJ 

ASNORDER 

REJODAT 

CDRRJ 

ASNORDER 

NCJODAT 

HISTJ 

DAYSADDED 

NCJODAT 

PROJJ 

DAYSADDED 

SHDESC 

MISCJ 

FTILLTQNS 

YARDID 

YARDS 

CHLENGTH 

REJODAT 

PROJJ 

DATADATE 

NCJDAT 

DESCJ 

TIMDNT 

NCJODAT 

CURRJ 

DAYSADDED 

REJODAT 

HISTJ 

DATADATE 

REJODAT 

CURRJ 

DATADATE 

NCJODAT 

HISTJ 

ASNORDER 

NCJODAT 

PROJJ 

ASNORDER 

SHDESC 

MISCJ 

DATASOURCE 

YARDID 

YARDS 

OEHEIGHT 

REJODAT 

PROJJ 

DATASOURCE 

NCJDAT 

DESCJ 

DATASOURCE 

NCJODAT 

CURRJ 

ASNORDER 

REJODAT 

HISTJ 

DATETYPE 

REJODAT 

CDRRJ 

DATETYPE 

NCJODAT 

HISTJ 

DATADATE 

NCJODAT 

PROJJ 

DATADATE 

SHDESC 

MISCJ 

DA.TADATE 

YARDID 

YARDS 

CH DEPTH 

REJODAT 

PROJJ 

ENTRYEX 

NCJDAT 

DESCJ 

DATADATE 

NCJODAT 

CDRRJ 

DATADATE 

REJODAT 

HISTJ 

DATASOURCE 

REJODAT 

CURRJ 

DATASOURCE 

NCJODAT 

HISTJ 

DATETYPE 

NCJODAT 

PROJJ 

DATASOURCE 

SHDESC 

MISCJ 

ENTRYDATE 

YARDID 

YARDS 

RAILDIST 

REJODAT 

PROJJ 

ENTRYDATE 

NCJDAT 

DESCJ 

ENTRYDATE 

NCJODAT 

CURRJ 

DATETYPE 
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Table  5-5.  List  of  Field  Appearing  in  Each  Relation 


m 


m 


REJODAT 

HISTJ 

ENTRYfil 

REJODAT 

CDRRJ 

ENTRYBX 

NCJODAT 

HISTJ 

DATASODRCE 

NCJODAT 

PROJJ 

ENTRYEX 

SHDESC 

MISCJ 

ENTRYEX 

YARDID 

YARDS 

LOCKNAME 

NCJDAT 

DESCJ 

ENTRYfiX 

NCJODAT 

CDRRJ 

DATASODRCE 

REJODAT 

HISTJ 

F,NTRYDA.TE 

REJODAT 

CDRRJ 

ENTRYDATE 

NCJODAT 

HISTJ 

ENTRYfiX 

NCJODAT 

PROJJ 

ENTRYDATE 

YARDID 

YARDS 

MINLOCKLEN 

NCJODAT 

CDRRJ 

ENTRYEX 

NCJODAT 

HISTJ 

ENTRYDATE 

NCJODAT 

PROJJ 

ADTOMOD 

YARDID 

YARDS 

HINLOCKWID 

NCJODAT 

CDRRJ 

ENTRYDATE 

NCJODAT 

PROJJ 

PROGVARl 

YARDID 

YARDS 

OPENED 

NCJODAT 

PROJJ 

PROGVAR2 

YARDID 

YARDS 

CLOSED 

NCJODAT 

PROJJ 

SDBRELDMAP 

YARDID 

YARDS 

BECAME 

YARDID 

YARDS 

DATASODRCE 

YARDID 

YARDS 

DATADATE 

YARDID 

YARDS 

ENTRYDATE 

YARDID 

YARDS 

ENTRYfiX 

Table  5-6.  Annotated  List  o£  Central  Data  Base  Fields 


ADDRESS 

APPRO P 
APPRO  P_AWD 

ARRIV 
ASNORDER 
AUTO MOD 

AWARD 

AWD_ST 


BEAM^OA 

BEAM.WL 

BECAME 

CHDEPTH 

CHHEIGHT 

CHLEMGTH 

CHWIDTH 

CLASS 

CLOSED 

CMETHD 


_ 


street  address  of  the  establishmentr  including 
state  and  zip. 

Job  appropriation  date. 

Length  of  time  required  between  appropriation  and 
award. 

Date  repair  job  arrives  in  yard. 

Special  variable  used  only  by  the  assigner  module. 

If  yesr  assigner  may  automatically  modify  schedule 
dates. 

Job  award  date. 

Length  of  time  required  between  job  award  and  start 
dates. 

Overall  beam  of  ship,  including  flight  deck. 

Beam  of  ship  at  the  waterline. 

Name  of  yard  that  yard  became  after  closing,  if 
any. 

Depth  of  channel  at  shallowest  point  in  sea  access 
lane. 

Maximum  height  of  a  ship  above  waterline  to 
traverse  sea  access  1 

Maximum  length  a  ship  may  be  and  still  traverse  sea 
access  lane. 

Maximum  beam  a  ship  may  have  (waterline)  and  still 
traverse 

Ship  class  name,  e.g.  DDG-51 

Date  establishment  closed  its  doors,  under  given 
name. 

Construction/work  method  used  on  ship  job/. 


Table  5-6.  Annotated  List  of  Central  Data  Base  Fields 


fJELPMME 

CODE071 

COMMENT 

COMMENT 

COMMISSION 

COMNUM 

COMPLEXGRP 

COMPLEXGRP 

CUSTOMER 

DATADATE 

DATASOORCE 

DATETYPE 

DAYS ADDED 

DEACT 

DEFLTAWDAY 

DELIVERY 

DEVACRES 

DISPOSN 

DL_COM 

DRYDOCK 

DUMMY 


_J2E5i2j;PIIi2M _ 

Yard  identification  code  number  used  by  SEA  071. 

A  65-character  line  of  comments. 

Holds  text  information,  usually  comments  about 
other  data. 

Date  ship  is  commissioned  or  recommissioned. 

Ship's  commissioning  number.  «1  except  for 
reactivation  jobs. 

Complexity  group  ships  of  class  belong  to  for 
assignor  update 

purposes 

Code  name  indicating  the  buyer  of  the  given  ship 
job. 

Date  the  data  in  the  data  record  was  obtained. 

Source  data  in  record  was  gathered  from. 

Code  indicating  whether  dates  are  actuals  or 
projections. 

Number  of  days  added  to  ship's  life  by  jhob.  0  for 
newcon  jobs. 

Ship's  deactivation  date  for  given  commissioning. 

Default  award  day.  Used  by  the  assignor  to 
determine  the 

Date  ship  is  delivered. 

Number  of  developed  acres  owned  by  yard  at  given 
site. 

Disposition  of  ship  upon  deactivation,  e.g.  SCRAP. 

Amount  of  time  required  between  ship  delivery  and 
commissioning. 

Date  ship  is  drydocked. 

Dummy  field;  not  used  for  any  purpose. 


Table  5-6.  Annotated  List  of  Central  Data  Base  Fields 


IlELSS^ 

ENTRY_BY 

ENTRY.  DATE 

FSCM 

FULLNAME 
FULL_ DRAFT 
FULL.  HITE 
FULL. TONS 
HOME PORT 
HULL 
JOBID 

JOBTYP 

JSTYP 

KEEL 

KL_LN 
LAUNCH 
LAUN_ DRAFT 
LAUN.HITE 
LAUN.TONS 
LENGTH.OA 
LENGTH.  WL 
LIFE 

LITE.  DRAFT 


.jiESSsmism _ 

Name  of  user  who  originally  entered  or  updated  data 
in  this  recrd 

Date  this  data  was  entered  or  updated  (not 
modified) . 

Federal  code  number  identifying  the  company /pi ant. 
Full  descriptive  name  for  legal  code  value. 

Draft  of  ship  when  fully  loaded. 

Height  of  ship  above  waterline  when  fully  loaded. 
Displacement  of  ship  when  fully  loaded. 

Home  port  code  name. 

Individual  ship's  hull  number. 

A  code  number  uniquely  identifying  the  given  job, 
in  combination 

Ship  job  type  code,  e.g.  NEWCON  or  REACT. 

Job  sequence  type  code,  e.g.  LEAD  or  ORDFOL. 

Date  keel  is  laid,  or  for  reactivation/conversion, 
of  drydocking. 

Time  required  between  laying  of  keel  and  launch. 
Date  ship  is  launched  or  undocked. 

Draft  of  ship  when  it  is  launched. 

Height  of  ship  above  waterline  when  it  is  launched. 
Displacement  of  ship  when  it  is  launched. 

Overall  length  of  ship,  including  flight  deck. 
Length  of  ship  at  the  waterline. 

Standard  service  life  of  ships  of  the  class,  in  the 
absence 

Draft  of  the  ship  when  light. 


Table  5-6.  Annotated  List  of  Central  Data  Base  Fields 


LIT^_HITE 

LITE_TONS 

LNUH 

lildl 

LOCKNAME 

MINLOCKLEN 

KINLOCKWID 

NCJOBT 

OCEAN 

OPENED 

PARENT 

PRNTNAME 

RAILDIST 

REJOBT 

SCENARIO 

SHIPNAME 

SMSA 

START 

STATE 

ST_KL 


-DESfiRIPIJQH _ 

Height  of  the  ship  above  waterline  when  light. 

Displacement  of  the  ship  when  light. 

Line  number  counter  for  comments  or  other  text. 

Amount  of  time  required  between  ship  launch  and 
delivery. 

Name  of  minimum-size  lock  in  yard's  sea  access 
channel . 

Length  of  the  minimum-size  lock  in  the  yard's  sea 
access  channel. 

Width  of  the  minimum-size  lock  in  the  yard's  sea 
access  channel. 

Job  type  code  for  new  construction  jobs. 

Legal-value  name  of  ocean  the  yard's  access  channel 
leads  to. 

Date  the  facility  opened. 

Name  of  the  establishment's  parent  corporation,  if 
any. 

Name  to  print  on  reports 

Distance  to  nearest  rail  link. 

Job  type  code  for  repair-type  jobs. 

Name  of  ALIAS  scenario  given  data  record  belongs 
to. 

Full  name  of  ship. 

Standard  Metropolitan  Statistical  Area  code  number. 
Date  of  start  of  work  on  job. 

Abbreviated  name  for  state  the  establishment  is  in. 

Amount  of  time  required  between  start  of  work  and 
keel-laying. 


5-35 


Table  5-6.  Annotated  List  of  Central  Data  Base  Fields 


fJELDM&ME 

SUPSHIP 

TIMONT 

TIMUNT 

TOTACRES 

USEDACRES 

WATERWAY 

YARD 

YARDNAME 


_DESX;EimiJH _ 

Code  name  for  SUPSHIP  office  supervising  the  yard. 

Indicates  the  units  that  an  associated 
time-oriented  data 

field  is  expressed  in;  e.g.  MONTHS 

Total  acres  owned  by  the  establishment. 

Number  of  acres  now  in  use  by  the  establishment. 

Name  of  the  waterway  that  is  the  yard's  principal 
sea  access 

Shipyard  name,  short  (common  usage)  version. 

Full  name  of  the  shipyard. 

Legal- value  library  field  name  which  must  be  YES  or 


YESNO 


6.0  USINGL^XIEMARIQS 

Each  relation  in  the  central  ALIAS  data  base  is  effectively 
partitioned  into  sections  called  "scenarios".  The  partitioning 
is  done  according  to  the  values  of  the  SCENARIO  fields  the  first 
one  in  each  relation.  All  records  belonging  to  a  given  scenario 
will  have  that  scenario's  name  in  their  SCENARIO  field. 

This  arrangement  was  made  to  allow  data  for  multiple 
studies  to  coexist  in  the  single  ALIAS  data  base  simultaneously. 
Since  alteration  of  data  vcdues  is  a  key  tool  used  in  ALIAS 
analyses,  it  would  have  been  crippling  to  force  everyone  to  use 
the  same  data. 

One  problem  with  this  arrangement  has  to  do  with  data  base 
updating.  Say  there  are  10  scenarios  in  existence.  Each  of 
these  will  have  data  for  current  jobs  in  the  relations  in  the 
.CURRJ  group.  Say  that  the  scenarios  differ  only  in  their 
projected  jobs  data,  and  that  their  owners  all  want  to  use  the 
latest  current  job  data.  Does  current  job  data  updating  have  to 
be  done  10  times,  once  per  scenario? 

The  answer  depends  on  the  structure  of  the  scenarios. 

There  must  be  data  for  each  scenario  in  each  relation,  but  there 
is  a  distinction  to  be  made  between  data  being  tfsed  by  a  scenario 
and  data  belonging  to  a  scenario.  When  a  data  record  belongs  to 
a  scenario  it  has  that  scenario's  name  in  its  scenario  field. 

But  other  scenarios  can  use  this  data  record,  the  only 
restrictions  being  that  they  cannot  change  the  record,  and  they 
cannot  have  any  records  of  their  own  in  the  same  relation. 

Each  scenario  has  a  map  which  tells  it  which  data  records 
to  use  in  each  central  data  base  relation.  The  map  consists  of  a 
list  of  SCENARIO  field  values,  one  per  relation.  If  the  map  has 
a  given  scenario's  own  name  for  a  given  relation,  then  the  data 
with  that  name  in  the  SCENARIO  field  in  that  relation  belongs  to 
that  scenario,  and  the  scenario  is  said  to  be  a  "direct”  user  of 
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that  data.  If  the  map  has  some  other  scenario's  name,  then  the 
scenario  is  an  "indirect”  user  with  read  privileges  for  the  data 
but  no  change  privileges. 


For  the  10-scenario  ex^unple  above,  the  current  job  updating 
would  have  to  be  done  only  once  (say  for  scenario  "MAIN”)  as  long 
as  the  other  9  scenarios  were  indirect  users  of  NAIN's  current 
job  data. 

The  "structure"  of  a  scenario  is  just  its  pattern  of 
direct/indirect  use  over  data  base  relations. 

You  must  know  how  to  create,  use,  and  modify  scenarios  in 
order  to  make  effective  use  of  the  ALIAS  Command  System  and  mod¬ 
ules,  and  you  must  understand  how  a  scenario's  structure  influ¬ 
ences  the  manner  in  which  you  make  data  base  queries.  These  are 
the  subjects  of  this  section. 

6.1  CONTROLLING  SCENARIOS 

Access  to  the  capabilities  which  let  you  use  and  manipulate 
scenarios  is  centered  in  the  Command  System  scenario  menu,  repro¬ 
duced  in  Figure  6-1.  There  are  five  basic  functions:  choice, 
creation,  deletion,  modification,  and  listing. 


6.1.1 


Whenever  you  use  the  Command  System  you  must  have  a 
"current"  scenario;  all  the  data  you  see  will  be  associated  with 
it.  You  will  be  prompted  for  the  name  of  the  scenario  you  want 
to  start  out  with  when  you  first  run  the  Command  System,  but  you 
can  use  a  different  one  at  any  time  by  choosing  option  1  in  the 
Command  System's  scenario  menu.  This  will  result  in  the  menu 
shown  in  Figure  6-2,  in  which  you  are  expected  to  give  the  name 
of  the  scenario  you  wish  to  change  to.  If  you  have  access  to  it 
and  no  one  else  is  using  it  at  the  time  the  change  will  be  made 
and  you  will  be  returned  to  the  Command  System. 
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Figure  6-1.  Oonnumd  System  Scenario  Qioioe  Menu 


Menu  is  SCQl 


*  ALIAS  OSMHAND  SYSOEM  *  Scenario  is  DEMD 


SCENARIO  SYSOEN  MENU 
CHOOSE  A  DIFFERENT  SCENARK)  T)  WORK  WnS 
CRBAOE  A  SCENARIO 
DOiEU;  (URRENOLY  EXISTING  SCENARIOS 
LIST  OURRENILY  EXISTING  SCENARIOS 
SEND  LIST  OF  EXISTING  SCENARIOS  T)  LINE  IRINTER 
MGDIFY  OHE  lAKEUP  OF  AN  EXISTING  SCENARIO 


GOftlAND: 


Figure  6-2.  Menu  for  uwice  of  Scenario  to  Use 


Scencurio  choice  options  indude: 


? 

@ 

@naine 

neme 


presides  help 
lists  existing  scenarios 
lists  the  composition 
of  the  'name*  scenario 
makes  the  'nme'  sceneulo 
your  currmit  scenario 


Current  scenario  is 

exits  scenario  choice  system 
moves  you  into  scenario 
creation  menu 
re-displeys  this  menu 


You  can  also  give  any  of  the  commands  listed  at  the  top  of 
Figure  6-2  in  response  to  the  command  prompt.  These  will  be 
covered  in  detail  in  Section  6.1.6. 


6.1.2 

You  will  probably  want  to  create  new  scenarios  whenever  you 
start  a  new  study,  or  when  you  want  to  construct  a  variant  of  an 
existing  study.  Doing  this  allows  you  to  make  data  changes 
freely  while  retaining  the  data  from  older  studies  in  the  exact 
form  you  left  it  in. 


Before  sitting  down  to  perform  the  creation,  give  some 
thought  to  the  structure  you  want  the  new  scenario  to  have.  Most 
scenarios  start  out  as  a  combination  of  copies  of  some  of  the 
data  in  one  or  more  existing  scenarios  and  patterns  of  indirect- 
access  use  for  the  rest  of  their  data.  You  will  almost  never 
want  to  create  a  scenario  that  is  a  completely  blank  slate,  since 
you  will  have  an  enormous  data  entry  task  to  get  it  ready  for 
use. 


First  decide  which  scenario (s)  you  want  to  take  data  from. 
It  is  best  if  it  all  comes  from  a  single  existing  scenario,  since 
you  can  then  be  sure  that  the  data  you  start  out  with  is  inter¬ 
nally  consistent.  You  are  free  to  combine  data  from  several 
scenarios,  but  you  may  have  to  correct  consistency  problems  be¬ 
fore  you  will  be  able  to  use  the  new  scenario.  For  example,  if 
you  take  yard  data  from  scenario  A,  and  projected  jobs  data  from 
scenario  B,  and  B  contains  a  job  to  be  done  at  yard  X  for  which  B 
has  data  but  A  does  not,  you  will  either  have  to  delete  the  job 
or  add  data  for  yard  X  to  your  new  scenario.  A  report  of  such 
problems  will  be  produced  at  the  close  of  the  creation  process  to 
help  you  identify  and  correct  them. 


Make  your  data  source  decisions  on  the  basis  of  the  data 
groups  listed  in  Table  5-3  (or  Table  6-1  below) .  During  creation 
everything  is  done  in  terms  of  sets  of  relations,  which  basically 


6-4 


Table  6-1.  List  of  Data  Base  Sets  and  Relations 


SET 

RELATION 

CURRJ 

NCJOCOM. CURRJ 
NCJODAT. CURRJ 
RE JOCOM. CURRJ 
RE JODAT. CURRJ 

DESCJ 

NCJDAT. DESCJ 
NCJDCOM. DESCJ 

HISTJ 

NCJOCOM. HISTJ 
NCJODAT. HISTJ 
RE JOCOM. HISTJ 
RE JODAT. HISTJ 

MI  SCI 

DEACOM.MISCJ 

DEACT.MISCJ 

SHCOMT.MISCJ 

SHDESC.MISCJ 

SHLIFE.MISCJ 

MNUREL 

ASNPRM. MNUREL 
ENVRN. MNUREL 
FLREPT.MNTJREL 
LCCREF. MNUREL 
VALCLS. MNUREL 
VAL YDS. MNUREL 
VLJTYP. MNUREL 
VLRJOB. MNUREL 

PROJJ 

NCJOCOM. PROJJ 
NCJODAT. PROJJ 
RE JOCOM. PROJJ 
RE JODAT. PROJJ 

YARDS 

YARDCOM. YARDS 
YARDID. YARDS 
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correspond  to  the  contents  of  these  groups,  with  all  the  rela¬ 
tions  in  the  same  set  getting  the  same  treatment.  If  you  need  to 
treat  relations  within  the  same  set  differently,  you  can  use  the 
scenario  modification  machinery  to  do  it  after  the  creation  is 
complete. 

Once  you  have  decided  where  the  data  in  each  set  will  come 
from,  decide  (by  set)  whether  you  will  need  to  make  changes  to 
it.  For  sets  where  no  changes  are  needed,  you  can  use  the  data 
in  the  source  scenario  indirectly  instead  of  having  a  copy  of  it 
made.  This  makes  the  creation  process  go  faster,  economizes  on 
disk  space,  and  may  reduce  your  data  entry  burden.  But  if  you 
know  that  the  owner  of  the  source  scenario  will  be  making  changes 
to  the  data  which  you  will  not  want  to  show  up  in  your  new 
scenario,  or  if  you  anticipate  needing  to  make  changes  yourself, 
a  copy  of  the  source  data  must  be  made  that  will  belong  to  your 
scenario  and  that  you  will  use  directly. 

All  of  these  decisions  are  reversible  using  the  scenario 
modification  machinery;  in  cases  where  you  are  uncertain  of  the 
best  strategy,  keep  in  mind  that  you  can  change  your  mind  later. 

Once  you  have  made  your  decision,  choose  option  2  on  the 
Command  System's  scenario  menu.  This  will  bring  up  the  menu 
shown  in  Figure  6-3,  in  which  you  will  be  prompted  for  the  name 
of  your  new  scenario  (it  must  be  unique  and  less  than  12  char¬ 
acters),  for  a  description  of  it  (up  to  24  lines),  and  for  some 
decisions  about  the  access  others  will  have  to  it.  You  will  be 
asked  if  users  other  than  yourself  should  be  allowed  to  look  at 
the  scenario;  if  you  say  yes,  any  ALIAS  user  will  be  able  to 
"run”  the  scenario  and  inspect  its  data.  You  cannot  really 
prevent  inspection  of  the  data  by  valid  ALIAS  users  in  any  case, 
since  queries  can  be  made  using  RELATE,  but  you  can  deny  them  the 
conveniences  of  the  Command  System  and  DBU  by  saying  no. 
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Figure  6-3.  Scenario  Creation  Menu,  Stage  1 


Current  scenario  is 

Scenario  creation  options  include: 

?  provides  help  I  exits  soencurio  choice  ^stenv 

@  lists  existing  scenarios  I  re-displays  this  maiu 

name  specifies  the  name  of  your  I  @name  lists  the  ccroposition 

new  scenario  I  of  the  'name'  scenario 


SCENARIO  CREATION— SffiGE  1 

NAME  of  new  scenario,  or  COMMAND:  I2H0 

Do  you  wish  to  allcw  all  ALIAS  users  to 
examine  the  contents  of  this  scenario?  Y 

Do  you  wish  to  allow  all  ALIAS  users  to 
modify  the  contents  of  this  scenario?  Y 

Please  give  a  description  of  this  scenario.  Terminate  it  with  a  '//'  line. 


You  will  also  be  asked  if  other  users  should  be  allowed  to 
change  the  scenario's  contents.  If  you  say  yes,  then  others  will 
not  only  be  able  to  see  your  data,  but  will  be  able  to  change  it 
as  well.  If  you  say  no,  ALIAS  security  is  sufficient  to  prevent 
anyone  else  from  making  changes  to  your  data. 

After  you  respond  to  these  questions  the  menu  shown  in 
Figure  6*'4  will  appear  (this  one  is  a  copy  from  the  sample 
session  in  Section  3) .  Here  you  will  be  prompted  for  your 
scenario  structure  decisions.  You  will  be  asked  for  the  source 
scenario  for  data  for  each  set.  If  you  want  to  start  with  a 
clean  slate  in  any  set,  respond  with  the  name  of  your  new 
scenario.  You  will  be  asked  if  you  will  want  to  make  changes  to 
the  data  in  the  set;  say  yes  to  have  direct  access,  and  no  for 
indirect  access. 

Note  that  up  to  answering  of  the  questions  for  the  YARDS 
set  you  can  abort  the  creation  process  by  responding  with  a 
command.  Also  note  that  the  "PARAMS"  set  refers  to  the  contents 
of  the  Command  System  parameter  and  list  menus  (i.e.  to  the 
relations  stored  in  the  .mnurel  HP  file  group) . 

Once  you  have  made  your  responses  for  the  last  set,  the 
scenario  system  begins  construction  of  the  new  scenario.  It 
makes  up  the  cross  reference  list  of  SCENARIO  field  values  by 
relation,  and  makes  copies  of  the  data  in  any  relations  for  which 
you  specified  direct  access  (some  copies  will  always  be  neces¬ 
sary,  since  each  scenario  always  has  its  own  PARAMS  set) .  The 
copying  process  is  time-consuming  because  of  the  large  volume  of 
data  which  must  be  manipulated. 

ALIAS  assumes  you  want  to  use  the  new  scenario  immediately 
and  thus  makes  it  your  current  scenario  upon  completion  of  the 
creation  process. 


Figure  6-4.  Scenario  Creation  Menu,  Stage  2 


Current  scenario  is 

Scenario  creati<xi  options  include: 

?  provides  help  1  *  exits  scenario  choice  system 

@  lists  existing  scenarios  I  re-displeys  this  menu 

nane  specifies  tiie  name  of  the  I  @name  lists  the  ccmposition 

scenario  tc  take  data  frcm  I  of  the  'name'  scenario 

for  a  particular  EB  family.  I 

SCENARIO  CREATION— ST!k3E  2 

Rlease  give  the  name  of  the  scenario  to  take  data  for  grotp  CURIO  fron. 
(OfflAND  or  NAME:  fixit 

Will  you  want  to  make  ary  changes  to  the  data  in  this  groip?  n 

ELease  give  the  name  of  the  scenario  to  take  data  for  group  DESC7  from. 
CDmAND  or  NAME:  fixit 

Will  you  want  to  make  ary  changes  to  the  data  in  this  groi:p?  y 

ELease  give  the  nane  of  the  scenario  to  take  data  for  group  HISTJ  from. 
COf96\ND  or  NAME:  fixit 

Will  you  want  to  make  any  changes  to  the  data  in  this  group?  n 

ELease  give  the  name  of  the  scenario  to  take  data  for  group  MISCJ  from. 
ODIMAND  or  NAME:  fixit 

Will  you  want  to  make  ary  changes  to  the  data  in  this  group?  n 

ELease  give  the  nanne  of  the  scenario  to  take  data  for  group  PARAMS  from. 
QUMIAND  or  NAME:  fixit 

ELease  give  the  name  of  the  scenario  to  take  data  for  group  FRQJJ  frcm. 
(DMIAND  or  NAME:  fixit 

Will  you  want  to  make  ary  changes  to  the  data  in  this  group?  y 

ELease  give  the  name  of  the  scenario  to  take  data  for  groip  YARDS  from. 
(DI«AND  or  NAME:  fixit 


Will  you  want  to  make  ary  changes  to  the  data  in  this  group?  n 


6.1.3  Scenario  Deletion 

Choosing  option  3  of  the  Command  System's  scenario  menu 
brings  up  the  menu  shown  in  Figure  6-5.  Here  you  are  expected  to 
give  the  name  of  the  scenario  you  want  to  delete.  It  must  be  one 
you  created  yourself  (unless  you  are  a  DBA-level  user) r  and  no 
one  can  be  using  it  when  you  make  the  deletion  request.  If  these 
conditions  are  met  ALIAS  will  go  ahead  and  perform  the  deletion. 
Like  creation^  it  will  be  time-consuming.  ALIAS  must  look 
through  every  data  base  relation  in  which  the  scenario  had 
direct-access  data,  making  sure  it  all  is  deleted. 

Note  that  if  some  other  scenario  was  set  up  to  make  in¬ 
direct  use  of  data  in  the  one  being  deleted,  this  data  will  be 
transferred  to  the  other  scenario  rather  than  being  destroyed. 
Likewise,  data  which  the  deleted  scenario  was  using  indirectly 
will  be  unaffected  by  the  deletion. 

The  scenario  will  be  gone  once  you  have  deleted  it,  so  you 
should  do  so  only  when  you  are  sure  you  are  through  with  its 
contents. 

6.1.4 

Scenario  structure  modification  changes  the  map  that  a 
scenario  uses  to  find  its  data  in  central  data  base  relations, 
thus  effectively  changing  its  contents.  Five  types  of  modifi¬ 
cation  are  possible: 

1)  Conversion  of  data  in  a  relation  or  set  from  indirect- 
access  to  direct-access  status.  If  you  are  using  yard 
data  from  MAIN  and  find  yourself  needing  to  make  yard 
data  changes,  you  can  have  a  copy  of  MAIN's  yard  data 
made  which  will  belong  to  the  scenario  you  are  working 
with.  You  will  then  be  responsible  for  keeping  the  yard 
data  up  to  date,  of  course. 

2)  Changing  from  indirect  access  use  of  one  scenario's  data 
to  indirect  access  use  of  another's. 

3)  Changing  to  a  clean  slate  in  some  relation  or  set  of 
relations.  If  the  scenario  you  make  this  change  to  had 
its  own  direct-access  data  in  those  relations,  it  will 
be  deleted. 
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Figure  6-5.  Scenario  Deletion  Menu 


Scenario  deletion  options  include: 
?  provides  hdp 

@  lists  existing  scenarios 

@naine  lists  the  composition 
o£  the  'name'  scenario 
nane  makes  the  'nane'  scenario 
your  curreit  scenario 


CXirrent  scenario  is 

exits  sceneu:io  choice  system 
moves  you  into  scenario 
creation  menu 
re-displeys  this  menu 


SCENARIO  DELETION  MENU 
Name  of  scenario  to  delete,  or  Oonmand  character: 
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4)  Deletion  of  a  scenario's  direct  access  data  in  some 
relation  or  set  of  relations,  and  replacement  of  it  with 
a  copy  of  the  data  in  some  other  existing  scenario.  In 
effect,  the  creation  process  is  reproduced  for  selected 
relations. 

5)  Deletion  of  a  scenario's  direct  access  data  in  one  or 
more  relations,  and  "replacement"  of  it  with  indirect 
access  use  of  the  data  in  some  other  existing  scenario. 

You  can  make  these  changes  on  a  relation-by-relation  basis 
as  well  as  to  entire  sets  of  relations  (the  same  sets  used  during 
creation) . 

Choose  option  6  on  the  Command  System's  scenario  menu  when 
you  want  to  perform  a  modification.  The  menu  shown  in  Figure  6-6 
will  result.  You  are  expected  to  give  the  name  of  the  scenario 
you  want  to  modify.  If  you  have  change  privileges  for  it,  you 
will  be  passed  on  to  the  menu  in  Figure  6-7.  Here  your  principal 
task  is  to  choose  the  level  of  detail  at  which  you  will  make 
modifications.  If  you  give  the  CS  command  (Change  Set)  then  you 
will  make  your  modifications  on  the  same  sets  of  relations  which 
were  involved  in  the  creation  process.  If  you  give  the  CR 
(Change  Relation)  command,  then  changes  can  be  made  on  a 
relation-by- relation  basis.  The  LS  and  LR  (List  Set/Relation) 
commands  list  the  current  structure  of  the  scenario  you  are 
changing  by  showing  the  map  of  scenario  key  field  values  for  each 
set  or  relation. 

After  you  choose  one  change  mode  or  the  other,  the  menu 
shown  in  Figure  6-8  will  appear.  This  is  the  "workhorse”  menu  of 
the  modification  subsystem,  in  which  you  specify  the  changes  you 
want  made  using  the  syntax  ”set_name«new_source_scenario"  or 
"relation_name«new_source_ scenario".  A  list  of  the  current  sets 
and  relations  (whose  names  you  must  know  exactly)  is  provided  in 
Table  6-1  for  your  convenience.  After  you  give  one  of  these 
commands  (with  valid  names  on  both  sides  of  the  sign)  you 
will  be  prompted  with  the  usual  "Will  you  want  to  change  this 
data?"  sort  of  question.  An  answer  of  "yes”  causes  a  copy  to  be 
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Figure  6-6.  Soeneurio  Itodification  Menu,  Stage  1 


Scenario  modification  options  include: 

?  provides  help  I  *  exits  scenario  choice  system 

@  lists  existing  scenarios  I  re-displays  this  menu 

name  specifies  the  nane  of  the  I  ftiame  lists  the  composition 

scenario  to  modify  I  of  the  'name'  sceneurio 


CSANSE  SOHARIO  tAKEUP— SD^E  1 
NAME  of  scenario  to  modify,  or  COMMAND:  DEMO 


Figure  6-7.  Scenario  Modification  Menu,  Stage  2 


***  MODIFSfING  fAKEDP  OF  SCENARIO  DEMO  *** 
Scenario  modification  options  include: 


?  presides  help 

CS  change  cemposition  ty  family 

CR  chamge  cemposition  ty  file 

re-displays  this  menu 


I  exits  scenario  choice  system 

i  LS  list  cemposition  by  family 
I  LF  list  cemposition  by  file 


Figure  6-8.  Scenario  Madificaticxi  HenUf  Stage  3 


Scenario  modification  options  include: 

?  provides  help  I  exits  scenario  choice  system 

@  lists  current  scenarios  I  @ncnie  lists  composition  of  NAME 

re-displcys  this  m&ai  I  FAMlL^NB^r  SOUFO!  specifies  change 


CHANGE  SCENARIO  mKEUP— SIAGE  3 
D^EAMILl^NEW_SOtJRCE_SC2NARIO,  or  CDMMAND:  MISCII-FIXIT 

Do  you  want  a  copy  of  that  date  made  (no^only  read  it)  ?  Y 

Change  made. 

IB_FAMIL^^NW_SOURaL  SCENARIO,  or  ODMftND:  " 
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made  and  direct-access  status  to  be  given  to  the  changed  scenario 
for  the  data  in  the  given  set/relation,  while  "no”  yields  no  copy 
and  indirect  access. 


Use  the  following  combinations  of  responses  to  implement 
each  of  the  five  kinds  of  change  discussed  above: 

1)  Indirect- to-direct,  same  data  as  before. 

Command:  relation/set_name>source_scenario_name 
Response:  Yes 

Note  that  the  source_scenario_name  is  the  same  one 
listed  for  the  given  relation/set  by  using  the  LS  or  LR 
commands,  since  you  are  only  changing  the  access  status 
and  not  the  contents  of  the  scenario  in  this  case.  The 
difference  between  this  and  the  creation  syntax  is  the 
■yes"  response. 

2)  Indirect  use  of  A  -to-  indirect  use  of  B. 

Command:  relation/set_name*new_ source. scenario.. name 
Response:  No 

3)  Wipe  the  slate  clean. 

Command:  r el ation/set_neune«this_ scenario. name 
Response:  Yes 

This  will  delete  any  data  belonging  to  this.scenario  in 
the  given  relation  or  set,  so  use  with  care. 

4)  Direct  -to-  direct,  different  data. 

Command:  relation/set.name>new_source.scenario 
Response:  Yes 

This  will  delete  the  current  data  for  this.scenario  and 
replace  it  with  a  copy  of  that  from  new. source. scenario 

5)  Direct  -to-  indirect,  different  data. 

Command:  relation/set.naroeBnew.source.scenario 
Response:  No 

Like  4  but  no  copy  is  made. 


When  you  are  finished  making  changes,  or  just  want  to 
review  your  work  using  LS  or  LR,  give  the  command  to  return 
to  the  second  modification  menu. 


6.1.5 


You  can  find  out  the  names  of  existing  scenarios  by  giving 
options  3  or  4  on  the  Command  System's  scenario  menu.  Option  3 
types  them  on  your  terminal,  edong  with  their  descriptions,  while 
option  4  sends  the  list  to  the  printer  which  is  "current"  on  the 
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User  Environment  Parameter  menu  for  your  current  scenario.  This 
printed  list  can  optionally  include  the  structure  of  each 
scenario. 

6.1.6  Auxil 

Each  scenario  system  menu  shown  in  Figures  6-2  through  6-8 
has  a  list  of  auxiliary  commands  at  the  top^  commands  which  can 
be  given  to  aid  your  main  decision  in  the  menu.  Some  of  these 
perform  the  same  function  as  they  do  in  the  Command  System; 
returns  you  to  the  last  menu  you  were  looking  at,  retypes  the 
menu,  ”?"  causes  some  help  to  be  printed.  The  less  familiar  ones 
and  their  functions  are: 

+  Puts  you  in  the  scenario  creation  subsystem;  identical 
to  choosing  option  2  on  the  Command  System  scenario 
menu. 

@  Lists  the  names  of  existing  scenarios  and  their 

descriptions.  Identical  to  option  3  on  the  Command 
System  scenario  menu. 

@name  Lists  the  composition  of  the  ”name”  scenario,  at 

either  the  relation  or  the  set  level.  Essentially  lists 
the  internal  map  which  gives  the  SCENARIO  fielo  value 
for  each  relation/set  for  the  ”name”  scenario. 

6.2  BASIC  STRATEGY  FOR  USING  THE  SCENARIO  CAPABILITY 

The  scenario  system  provides  you  with  a  powerful  set  of 
tools  for  conducting  analyses,  but  the  ways  in  which  these  tools 
can  fruitfully  be  used  may  not  be  completely  clear.  This  section 
will  provide  a  few  rules  of  thumb  and  examples. 

There  are  two  main  rules  of  thumb  for  scenario  management. 
The  first  is  that  you  should  create  a  new  scenario  whenever  you 
come  to  a  point  in  an  analysis  where  you  are  about  to  try  some 
major  changes  which  you  think  you  might  have  to  reverse.  By 
trying  the  changes  on  a  copy,  rather  than  on  the  scenario  you 
have  painstakingly  worked  up,  you  can  get  back  to  your  pre-change 
point  instantaneously.  And  if  you  like  the  changes,  you  can 
always  delete  the  pre-change  scenario. 
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The  overhead  involved  in  creating  such  scenarios  need  not 
be  time-consuming  if  you  follow  the  second  rule  of  thumb,  which 
is  to  always  choose  indirect  access  to  source  scenario  data 
(answer  "no"  to  the  "Will  you  want  to  make  changes  to  this  data?" 
question)  over  direct  access  unless  you  are  sure  you  will  need  to 
make  changes.  Most  of  the  time  burden  in  scenario  creation  lies 
in  the  making  of  copies  of  source  scenario  data  to  permit  direct 
access  use;  by  minimizing  the  number  of  such  copies  you  will 
minimize  the  amount  of  time  required.  You  can  always  use  the 
modification  capability  later  to  convert  a  relation  or  set  from 
indirect  to  direct  access  status  if  you  need  to  make  changes. 

Many  studies  focus  on  manipulation  of  only  one  part  of  the 
data  base  (such  as  projected  SCM  jobs),  and  are  passive  users  of 
the  rest.  If  your  study  falls  in  this  category  you  need  only  set 
up  direct  access  to  the  relations  in  the  data  base  set  that  you 
are  working  with  intensively. 

You  can  use  the  scenario  modification  processor’s  "clean 
slate"  option  (method  3)  to  speed  your  work  in  some  cases.  For 
example,  if  you  decide  you  must  generate  a  completely  new  set  of 
projected  schedules  for  a  scenario,  you  could  go  into  the  as- 
signer,  delete  all  the  old  assignments,  and  type  in  the  new  ones. 
A  faster  method  would  use  the  modification  subsystem  to  delete 
all  the  records  for  your  scenario  in  relation  ncjodat. proj j ;  then 
you  would  only  need  to  type  in  the  new  ones  in  the  assigner. 

Suppose  you  have  a  study  in  which  you  are  varying  two  major 
things,  perhaps  the  number  of  shipyards  and  the  structure  of  the 
projected  SCM  program.  Suppose  you  have  six  scenarios  for  the 
study,  having  three  different  sets  of  yards  and  three  different 
sets  of  schedules,  and  you  want  to  combine  these  in  various  ways. 
The  best  method  of  accomplishing  this  is  to  create  a  new  working 
scenario  which  indirectly  accesses  the  data  in  one  or  more  of  the 
six  scenarios  you  have.  Then,  to  mix  and  match,  you  need  only 
use  the  modification  subsystem  to  change  from  indirect  access  to 
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scenario  A's  schedules  to  indirect  access  to  scenario  B's,  and  so 
forth.  Since  no  data  deletion  or  copying  is  involved,  almost  no 
time  is  consumed  implementing  the  change  in  structure. 

6 .3  SCENARIOS  AND  DATA  BASE  QUERIES 

It  is  important  to  keep  the  structure  of  a  scenario  in  mind 
when  you  use  RELATE  to  make  queries  involving  its  data.  Since 
the  scenario  field  appears  in  every  central  data  base  relation, 
you  must  specify  the  proper  field  value  in  your  query  in  order  to 
get  responses  which  use  only  the  data  for  the  scenario  you  are 
interested  in.  And  this  field  value  is  not  always  the  name  of 
your  scenario;  if  it  was  making  indirect  use  of  some  other  scen¬ 
ario's  data  in  a  given  relation,  that  other  scenario's  name  must 
be  specified  in  the  query. 

Suppose  you  want  to  know  the  state  in  which  each  projected 
SCN  ship  will  be  built.  To  do  this,  you  need  to  combine  infor¬ 
mation  in  the  ncjodat.proj j  schedule  relation  and  in  the 
yardid. yards  yard  relation.  Ncjodat.proj j  has  the  yard  each  ship 
is  to  be  built  at;  its  name  can  be  used  to  reference  into  the 
yardid. yards  relation  to  find  the  abbreviation  for  the  state  it 
is  located  in.  Further  suppose  that  the  scenario  you  are  using 
is  called  FYDP,  and  that  FYDP  has  no  yard  data  of  its  own,  using 
that  belonging  to  MAIN  instead.  Then  the  query  would  have  to 
read: 

OPEN  FILE  YARDID. YARDS ;MODE= SHARED 
OPEN  FILE  NCJODAT.PROJJ;MODE=  SHARED 

SELECT  CLASS,HULL,AWARD, YARD, YARDID. STATE  BY  STATE, AWARD, CLASS  & 
WHERE  NCJODAT.SCENARIO="FYDP"  AND  YARDID. SCENARIO= "MAIN "  AND  & 
NCJODAT. YARD- YARDID. YARD 

PRINT 


If  you  were  not  aware  that  FYDP  was  using  MAIN's  yard  data 
indirectly,  you  might  have  specified  NCJODAT. SCENARIO- 
YARDID. SCENARIO  AND  NCJODAT. SCENARIO- "FYDP",  in  which  case  you 


would  have  gotten  no  result,  since  there  were  no  records  in  the 
yardid. yards  relation  with  a  SCENARIO  field  value  of  "FYDP".  It 
is  a  good  idea  to  use  option  4  of  the  Conunand  System's  scenario 
menu  to  print  a  detailed  list  of  the  structure  of  a  scenario 
before  you  begin  to  make  queries  about  it  using  RELATE.  When  you 
do  work  with  the  DBU  or  any  other  module  accessed  via  the  Command 
System  these  details  are  handled  for  you  automatically. 


7.0 

The  Data  Base  Updating  System  (DBU)  is  your  primary  tool 
for  making  additions  and  changes  to  the  data  base.  It  is  a 
different  sort  of  environment  (see  Section  2)  than  most  of  the 
rest  of  ALIAS.  Its  primary  displays  are  f ill-in- the-blank 
screens  which  allow  you  to  look  at  and/or  change  each  field  of  an 
individual  data  record  from  a  relation. 

It  provides  many  other  services  associated  with  the  its 
basic  mission  of  DB  update  support.  This  section  will  describe 
its  commands  and  constituent  parts  in  detail. 

7.1  EXECUTING  THE  DBU 

The  DBU  is  accessed  by  choosing  option  3  on  the  Command 
System's  "TOP"  menu.  It  has  a  very  long  startup  lead  time,  but 
is  somewhat  different  from  other  ALIAS  modules  in  that  this  is  a 
one-time  cost.  After  you  use  it  once  in  a  Command  System  session 
and  exit  it,  it  remains  "on  hold".  The  next  time  you  want  it  in 
the  same  session  (just  choose  option  3  again)  it  will  come  up 
almost  immediately.  The  long  initial  delay  occurs  because  it 
needs  to  connect  to  most  of  the  data  dictionary  and  all  of  the 
legal  values  reference  library,  both  of  which  are  substantial 
data  bases  in  their  own  right. 

If  the  DBU  produces  garbled  displays  with  many  strange 
characters,  this  is  because  ALIAS  has  made  an  incorrect  guess 
concerning  your  terminal  type.  As  soon  as  the  display  is  stable 
(meaning  that  the  DBU  is  awaiting  your  command)  ,  type  E  and  hit 
the  return  key.  This  will  return  you  to  ALIAS,  where  you  must  go 
to  the  User  Environment  Parameters  menu  and  set  the  terminal  type 
parameter  to  the  correct  value. 

7.2  DBU  SCREEN  TYPES 

You  will  encounter  four  kinds  of  screen  while  using  the 
DBU,  exemplified  in  Figures  7-1  through  7-4  (bracketed  areas  in 
the  figures  are  the  "blanks"  you  would  see  on  a  video  display). 
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Figure  7-1 


Sanple  IBU  Menu  Screen 


***  SCREEN  SKEDJffiNU 
***  LAYOUT 

SCREEN  IS:  SKED_MENU  SCENARIO  IS:  DEMO 


?  for  help 


ALIAS  DATA  BASE  UPDATE  SYSTEM 
=choose  a  screen  to  use  by  number  or 


=NAME  juiT^ 


COMMAND: [ 


] 


1. 

2. 

3. 

4. 

5. 

6. 


PROJECTED  NEW  CONSTRUCTION, 
PROJECTED  REPAIR  O/ERHAUL, 
CURRENT  NEW  a»BTRUCTIC»I, 
CURRENT  REPAIR  OVERHAUL, 
HISTORICAL  NEW  CONSTRUCTION, 
HISTORICAL  REPAIR  OVERHAUL, 


CONVERSION  AND  REACTIVATION  JOB  SCHEDULES 
REFUELING,  AND  SLEP  JOB  SCHEDULES 
CONVERSION  AND  REACTIVATION  JOB  SCHEDULES 
REFUELING,  AND  SLEP  JOB  SCHEDULES 
CONVERSION  AND  REACTIVATION  JOB  SCHEDULES 
REFUELING,  AND  SLEP  JOB  SCHEDULES 


■■■■-  -  ,,  ^  may  be  changed  here=--— 

Please  place  a  cotnvand  or  cfJtion  raanber  after  OOMAMND  and  press  RETURN 


Figure  7-2.  Sairple  EBU  Data  Screen 


SCREEN  IS:  CLASSjCHABS 


lAIEOT  DATA 


SCENARIO  IS:  DEMO 


•s  ' 
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Figure  7-3.  Sanple  EBU  Connent  Screen 


SCREEN  IS:  CLASS_CHAR_OOMr  LATEST  DATA 


SCENARIO  IS:  DEMO 


ESC  L/D  inserts/deletes  ALIAS  DATA  BASE  UTOATE  SYSTEM  +  or  -  to  page 

. — s^--g=Con»naits  for  Ship  Class  Descriptions:— t  ?  ■-  — 


Class:  [ 


COMMAND: [ 


Data  Date  [  ] 

Entry  Date  [  ] 


Ccnnmts 


[ 

[ 

[ 

I 

[ 

[ 

[ 

[ 

[ 


] 

] 

] 

] 

] 

] 

] 

] 

] 


Entry  ^ 

■■■  Your  privileges  in  this  screen  are:  inspect=---  ■  -..-jissMa 
Changes  to  conments  will  be  posted  on  finish  with  this  iten  in  data  screen. 


Figure  7-4.  Sairple  DBU  Help  Screen 


SOffiEN  IS;  CLASS_MENOLHELP  SCENARIO  IS:  MMO 


?  for  more  help  ALIAS  DATA  BASE  UPDATE  SYSIEM  HELP  /  to  leave  help 
— iri — 1 - T-  ■description  of  the  purpose  of  the  class  menu - ■ 

G0»t1AND:[  ] 

Before  any  information  about  a  given  ship  class  (or  about  ships  of  that 
class)  may  be  altered  into  the  ALIAS  data  base,  a  basic  description  of  the 
class's  ships  must  be  entered  using  the  CLASSjCHARS  screen  (c^ion  1). 

If  any  projected  ships  are  to  be  of  the  newly  altered  class,  it  is  a  good 
idea  to  enter  planning  factors  for  the  class  (option  2) .  Without  planning 
factors  many  ALIAS  modules  will  not  be  able  to  operate  prc^rly.  Only  v4i^ 
you  choose  to  enter  ^)ecific,  'actual*  data  for  each  projected  ship  in  a  class 
can  the  entry  of  planning  factors  be  bypassed. 


— ^^amxaE;no  data  may  be  changed  here=------^=== 

Please  place  a  cocinand  after  CO^flAND  and  press  RETURN 


There  are  menu^  data,  comment/  and  help  screens.  Menu  screens 
perform  a  function  similar  to  that  of  Command  System  choice 
menus:  they  help  you  get  around  by  telling  you  what  your  options 
are. 

Data  screens  are  the  workhorses.  There  is  one  for  each 
central  data  base  relation  (more  or  less) .  Each  one  has  blanks 
which  correspond  to  its  relation's  fields/  and  can  thus  display  a 
single  record  from  the  relation  at  a  time. 

Comment  screens  are  auxiliaries  of  data  screens  (there  is 
one  for  each  data  screen) .  They  let  you  enter  textual  comments 
about  the  data  values  in  the  record  you  are  currently  working 
with  in  the  data  screen. 

Help  screens  display  text  which  tries  to  explain  where  you 
are  and  what  you  can  do.  Each  data  screen  has  its  own  dedicated 
help  screen/  and  there  are  a  large  number  of  general-purpose  help 
screens  which  describe  every  aspect  of  DBU  use. 

There  are  some  subtle  differences  in  the  operation  of  menu 
and  data  screens  on  the  one  hand  and  help  and  comment  screens  on 
the  other  which  place  minor  limitations  on  the  commands  you  can 
give  in  the  latter.  These  limitations  will  be  covered  below. 

7.3  KINDS  OF  COMMANDS 

Like  all  interactive  ALIAS  processors,  you  must  give  the 
DBU  commands  to  tell  it  want  you  want  done.  There  are  two  basic 
types  of  commands:  those  that  you  place  in  the  COMMAND  field 
(located  at  the  top  of  each  screen;  see  Figures  7-1  through  7-4) 
and  which  have  to  do  with  the  whole  screen  in  some  sense;  and 
those  which  have  to  do  with  only  one  field  on  the  screen,  which 
you  give  by  placing  the  cursor  on  the  field  and  hitting  the 
Escape  key. 
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COMMAND  field  conunands  are  generally  a  single  character 
(e.g.  "Q"  for  "quit");  you  place  them  in  the  field  and  hit  the 
RETURN  key  and  the  DBU  executes  them.  These  commands  do  one  of 
three  things:  cause  a  different  screen  to  be  displayed,  change  a 
DBU  mode  setting,  or  alter/save  the  data  record  showing  in  the 
"bl anks". 

Escape  commands  are  also  single  characters,  which  you  type 
in  response  to  a  prompt  given  after  you  hit  the  Escape  key. 

These  will  either  change  the  contents  of  the  field  the  cursor  was 
at  when  you  hit  the  Escape  key,  or  else  will  cause  some  help 
about  that  field  to  be  printed. 

Figure  7-5  is  the  help  screen  which  summarizes  the  commands 
available. 

7.4  MOVING  AROUND  IN  THE  DBU 

In  order  to  perform  the  primary  DBU  function  of  modifying 
the  data  base,  you  must  first  get  to  the  screen  which  handles  the 
data  you  want  to  modify.  There  are  three  basic  ways  of  doing 
this:  following  the  menus,  jumping  directly  to  the  screen,  and 
popping  back  to  it. 

If  you  have  just  started  the  DBU,  and  don't  know  the  name 
of  the  screen  you  need,  the  best  means  of  finding  it  is  by 
working  your  way  down  the  hierarchical  tree  formed  by  the  DBU's 
menu  screens.  These  menus  start  at  a  high  level  and  become  more 
detailed;  eventually  you  will  pick  an  option  on  one  which  will 
bring  up  the  data  screen  you  want.  For  example,  if  you  wanted  to 
change  schedule  planning  factor  data  and  were  looking  at  the 
MASTER  menu  shown  in  Figure  7-6,  the  best  choice  would  be  option 
1  (ship  classes),  since  planning  factors  are  at  the  class  level. 
This  would  bring  up  the  CLASS. MENU  screen,  also  shown  in  Figure 
7-6 .  This  menu  has  an  option  which  matches  what  you  want  exactly 
(2)  ;  choosing  it  results  in  display  of  the  SKED.PF.MENU  screen. 


/  to  leave  help 


7*  for  beginner's  help  ALIAS  DATA  BASE  UPDATE  SYSTEM  HELP 

ssunmcury  of  comnand  codes= 


OOM1AND:  [ 


USE 


7NAME 

C 

/ 


sNAME 

Q 


T  or 
L 

ESC  R 
ESC  ? 


TO  MCVE  TO 


TH 


USE 


Use 


help  sub^stem 

help  scre^  NAME 

coninent  screen 

top  screen  or  leave  help 

previous  screen 

next  screen 

jump  to  screen  NAME 

main  m^u  syston 

MPE  command  mode 

TOP  or  HP  editors 

set  INSPECTion  mode 

recalculate  dates 

help  for  field 

=no  data  may 


N 

K 

S 

B 

A 

D 

U 

M 

V 

ESC 

P 


] 


TO  AFFECT  FIELDS/ALTER  DB 


bring  next  data  item  to  screen 
clear  fields 

search  for  matching  data  item 
negate  search/ rewind  file 
add  screen  data  to  IB 
delete  screen  data  from  DB 
ipdate  DB,  alter  data  date 
modify  IB,  same  data  date 
verify  data  in  fields  ok 
next  legal  value  (fld=cursor) 
print  data  in  screen  set 
4-  page  forward/back,  this  itan 

ESC  I  or  D  insert/delete  lines  (ccmts) 
be  changed  here  —  -  ~~ - aM==- 


?x,  where  'x*  is  (xie  of  the  coimand  codes,  to  find  out  more  about  'x' 


?  for  help 


ALIAS  DATA  BASE  UPDATO  SYSIEN 
loose  a  screen  to  use  number  or 


-NAME  ju 


COMMAND:! 

1.  SHIP  CLASSES 

2.  SHIP  JGB  TYPES 

3.  SHIP  JOB  SCHEDULES 

4.  SHIP  YAPDS 

5.  SHIP  DEACnVATIONS 


No  data  may  be  changed  here -  - 

Please  place  a  cemnand  or  option  number  after  GOMAMND  and  press  REIUFN 


GREEN  IS:  CLASSJ1ENU 


SCENARIO  IS:  DEMO 


?  for  help 


ALIAS  DATA  BASE  0H3A!IE  SYSTEM 
‘Choose  a  screen  to  use  by  number  or 


‘NAME  ju 


COMMAND:  [  ] 

1.  CLASS  CHARACIERISrnCS 

2.  SCHEDULE  PLAIiUNS  FACTORS 


wr-in-Tr  rmr^rri—rr  n'  i.ilNq  data  may  bc  Changed  here*'  ■  ■  ■  ■  =^=====— 

Please  place  a  conmand  or  option  number  ^ter  OOMAMND  and  press  RETURN 


in  which  you  would  choose  eunong  different  kinds  of  planning 
factors,  finally  arriving  at  a  data  screen. 

This  process  is  reliable  but  somewhat  tedious,  especially 
after  you  have  some  experience  with  the  DBU.  If  you  know  that 
the  name  of  the  screen  you  want  to  use  is  NQ_SKED_PF,  but  you  are 
in  the  MASTER  menu,  you  can  still  have  it  displayed  immediately 
by  giving  the  command  "=NC_SKEp_PF".  You  can  give  the  jump  ("  =  ") 
command  in  any  data  or  menu  screen,  and  can  specify  the  name  of 
any  other  data  or  menu  screen.  Table  7-1  lists  all  DBU  screens 
by  category,  serving  as  a  reference  for  jumping. 

The  command  works  only  for  jumps  to  menu  and  data 
screens.  To  jump  to  a  particular  help  screen,  you  must  use  the 
command  "?HELP_SCREEN_NAME". 

You  can  also  change  screens  by  "backing  up".  If  you  were 
last  in  the  NQ_SKED_PF  screen,  but  are  now  in  the  PROJ_NC_SKED 
screen,  you  can  go  back  to  NQ_SKED_PF  just  by  giving  the 
command.  The  meaning  is  thus  similar  to  the  "*"  command  of  the 
Command  System.  The  DBU  keeps  a  history  of  the  last  eight  menu 
and  data  screens  you  have  used,  so  you  can  back  up  eight  times 
(there  is  unlimited  backup  for  help  and  comment  screens) .  If  you 
try  to  back  up  more  than  eight  times  you  are  always  left  in  the 
MASTER  menu. 

As  in  the  Command  System,  the  "/"  command  will  "pop  you  to 
the  top".  The  "top"  is  defined  as  the  MASTER  menu  if  the  command 
is  given  in  a  menu  or  data  screen,  and  the  last-used  menu  or  data 
screen  if  you  are  in  a  comment  or  help  screen. 

To  leave  the  DBU,  give  the  "Q"  (quit)  command  in  any  menu 
or  data  screen.  The  "E"  command  will  also  get  you  out  of  the 
DBU,  but  will  terminate  the  DBU  process,  forcing  you  to  pay  the 
initialization  time  penalty  the  next  time  you  want  to  use  it. 


COMMENT  INSPECTION/ENTRY  SCREENS 


CLASS_CHAR_COMT  Each  of  these  screens  is  associated  with 
CURR_NC_SKED_C  a  data  screen ^  and  is  intended  for  entry 
CURR^RE_SKED_C  and  modification  of  comments  about  the 
DEACTIVATE_COMT  data  displayed  on  the  associated  screen. 
HIST_NC_SKED_C  Comments  are  always  associated  with  a 
HIST_RE_SKED_C  particular  record  in  the  associated  data 
NC_SKED_PF_COMT  relation. 

PROJ_NC_SKED_C 

PROJ_RE_SKED_C 

YARD_CHARS_COMT 

DATA  ENTRY/MODIFICATION  SCREENS 

CLASS_CHARS  These  are  the  DBU's  data  entry  screens, 

CURR^NC_SKED  the  reasons  for  its  existence.  Names 

CURR_RE_SKED  are  mnemonic,  with  SKED  indicating 

DEACTIVATE  schedules,  HIST,  CURR,  and  PROJ  referring 

HIST_NC_SKED  to  historical,  current,  and  projected  epochs 

HIST_RE_SKED  respectively,  NC  and  RE  to  new  construction 

NC_JOB_TYPES  type  jobs  (reacts  and  conversions  too)  and 

NC_SKED_PF  to  repair-type  jobs  (includes  SLEPs) .  CHARS 

PROJ_NC_SKED  stands  for  characteristics,  PF  for  planning 

PROJ_RE_SKED  factors. 

RE_JOB_TYPES 

YARD_CHARS 

HELP  SCREENS  WHICH  TELL  ABOUT  A  MENU  OR  DATA  SCREEN 

CLASS_CHAR^HELP  These  help  screens  have  text  which  talks 

CLASS_MENU_HELP  about  "their"  data  or  menu  screen.  They 

C_NC_SKED_HELP  are  displayed  when  you  enter  a  "?" 
C_RE_SKED_HELP  in  that  screen.  The  names  are  mnemonic 
DEACTIVATE_HELP  and  similar  to  those  of  the  associated 
H_NC_SKED_HELP  data/menu  screens.  H,  C,  and  P  stand  for 
H_RE_SKED_HELP  HIST,  CURR,  and  PROJ  respectively. 
NC_SKED_PF_HELP 
P_NC_SKED_HELP 
P_RE_SKED_HELP. 

SKED_MENU_HELP 
SKED_PF_HELP 
YARD_CH ARS_H  EL  P 
YARD_MENU_HELP 
JOB_TYPE_HELP 


TABLE  7-1.  Annotated  List  of  DBU  Screens  By  Type 


SCREEN  PURPOSE 


HELP  SCREENS  WHICH  DESCRIBE  OVERALL  DBU  OPERATION 


BACKHELP 

CHAINHELP 

COMMANDHELP 

COMHANDHELPL 

CURSORHELP 

CURSORHELPL 

DCHECKHELP 

DELETEHELP 

HELPHELP 

IFIELDHELP 

JOINHELP 

JOINHELP2 

JUMPHELP 

LEGALHELP 

MAINHELP 

MOVEHELP 

NEXTHELP 

PUSHHELP 

READHELP 

SLOWHELP 


CLASS_MENU 

JOB_TYPE_MENU 

MASTER 

SKED_MENU 

SKED_PF_MENU 

YARD.MENU 


How  to  retrace  your  steps  through  the  screens 
you  have  been  in  already. 

How  to  use  menu  screens  to  find  your  way 
around. 

General  discussion  of  types  of  DBU  commands. 
Table  of  DBU  command  code  characters. 

General  discussion  of  the  screen  cursor  and  how 
to  move  it  around  the  screen. 

Table  of  control  codes  for  cursor  movement. 
General  discussion  of  data  validation  which  is 
done. 

What  happens  when  you  try  and  delete  data. 

How  to  use  the  help  subsystem. 

Further  discussion  of  screen  enhancements. 

Why  and  how  join  checking  is  done  as  part  of 
the  validation  process. 

How  to  have  the  DBU  display  the  next  screen  you 
want  to  use  without  going  through  the  menus. 

Why  and  how  legal  value  checking  is  done  as 
part  of  the  validation  process. 

General  introduction  to  DBU  and  to  the 
system-level  help  screens. 

General  discussion  of  how  to  move  from  screen 
to  screen. 

How  to  move  to  the  default  next  screen. 

How  help  and  comment  screens  are  entered  and 
exited. 

General  discussion  of  how  to  interpret  the 
display  enhancements  used  for  screen  fields. 

Why  is  this  Mil  thing  so  slowr  and 
inconsistently? 

MENU  SCREENS 

These  screens  guide  you  to  the  proper 
data  screen  for  your  purposes. 
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DBU  security  may  prevent  you  from  seeing  a  particular 
screen.  See  the  Data  Base  Administrator  if  you  feel  this  is  a 
mistake. 

7.5  ON-LINE  HELP 

The  DBU  has  very  extensive  on-line  help  to  aid  you  at  the 
terminal.  It  is  organized  in  the  form  of  a  help  "subsystem” 
consisting  of  a  large  number  of  text  screens.  You  can  activate 
the  subsystem  at  any  time  by  giving  the  "?"  command.  The  result 
will  be  a  help  screen  dedicated  to  the  menu  or  data  screen  you 
were  inr  describing  its  purpose  and  operation.  It  is  a  good  idea 
to  read  the  help  screen  any  time  you  use  a  new  data  screenr  since 
it  will  inform  you  of  any  unusual  features. 

If  you  require  additional  help,  you  can  give  the  "?" 
command  again  in  the  help  screen.  Help  screens  are  linked 
together  in  a  chain  which  you  can  traverse  by  repeated  issuance 
of  the  ”?”  command.  To  exit  the  chain  without  popping  back 
through  all  the  help  screens  you  have  read,  just  issue  the  "/" 
command  and  you  will  be  back  in  the  menu  or  data  screen. 

As  noted  in  the  previous  section,  you  can  also  jump 
directly  to  any  help  screen  by  tacking  its  name  onto  the 
(e.g.,  "7HELPHELP")  .  One  of  the  most  commonly  used  help  screens 
is  the  summary  of  available  commands  (shown  in  Figure  7-5) ,  whose 
name  is  "COMMANDHELPL". 

Help  is  available  about  individual  fields  on  a  data  screen 
as  well  as  about  the  screen  as  a  whole.  To  find  out  what  a  field 
is  for,  move  the  cursor  to  it,  hit  the  Escape  key,  and  give  the 
”?”  Escape  command.  This  will  bring  up  a  special  field-help 
screen  which  will  query  the  data  dictionary  about  the  field  and 
display  the  results  for  your  perus'jl. 


7.6  USING  DATA  SCREENS 

7.6.1 

When  you  have  a  data  screen  showing  on  your  display,  the 
first  thing  you  will  need  to  do  is  decode  its  format.  There  will 
be  a  title  just  under  the  "ALIAS  DATA  BASE  UPDATE  SYSTEM"  header, 
and  a  hint  at  the  bottom,  which  will  give  you  some  indication  of 
what  the  screen  is  for  and  how  to  use  it.  There  will  be  a 
COMMAND  field,  showing  in  inverse  video,  just  under  the  title. 
This  is  where  you  put  your  command  characters  before  hitting  the 
carriage  return  key. 

Embedded  in  the  line  of  equal  signs  at  the  bottom  of  the 
screen  will  be  an  indication  of  your  data  change  privileges  in 
the  screen.  If  any  of  Inspect,  Add,  Modify,  Update,  or  Delete  do 
not  appear  in  the  list  then  you  will  not  be  allowed  to  give  the 
corresponding  command.  A  lack  of  privileges  can  result  from 
denial  by  the  DBA.  A  more  likely  cause  when  you  find  yourself 
with  Inspect  privileges  only  is  the  structure  of  the  scenario  you 
are  using:  if  the  scenario  indirectly  accesses  the  data 
belonging  to  another  scenario  in  the  relation  your  current  data 
screen  serves,  you  will  naturally  not  be  allowed  to  make  any 
changes.  If  you  have  a  need  to  make  changes,  you  must  first 
alter  the  structure  of  the  scenario. 

There  will  be  a  number  of  labeled  blanks  or  windows.  These 
are  the  areas  where  field  values  from  the  data  base  will  be 
displayed.  There  are  four  kinds  of  window;  you  can  distinguish 
them  by  their  differing  screen  enhancements.  Those  which  are  in 
inverse  video  (bright  green  or  white)  are  "ordinary"  fields, 
meaning  that  you  can  put  whatever  value  you  please  there  (except 
you  can't  put  words  in  a  date  field  or  a  numeric  field). 

Those  which  are  underlined  are  "legals"  fields,  meaning 
that  whatever  value  is  there  must  match  one  on  a  relatively  short 
list  of  legal  values.  You  can  flip  through  this  list  for  any 


legals  field  by  placing  the  cursor  on  the  field,  hitting  the 
Escape  key,  and  giving  the  +  or  -  command  to  go  forward  or 
backward  through  the  list. 

Those  which  are  both  underlined  and  in  inverse  video  are 
"key"  fields.  These  are  typically  part  of  the  unique  key  field 
set  for  the  relation  the  screen  is  servicing.  In  order  to  make 
additions  or  modifications  to  the  contents  of  the  relation,  you 
will  have  to  put  values  in  these  fields  which  are  consistent  with 
the  rest  of  your  scenario.  For  example,  you  cannot  put  "XYZ "  in 
the  "yard"  window  of  a  schedule  screen  unless  there  is  data  for  a 
yard  named  "XYZ"  in  the  yardid. yards  relation  for  your  scenario. 

Some  windows  will  have  no  enhancement  at  all,  such  as  the 
entry  date  field  which  appears  at  the  bottom  right  of  most 
screens.  This  means  that  you  cannot  change  the  value  of  the 
field;  its  values  will  be  set  automatically  by  the  DBU. 

The  DBU's  data  validation  logic  will  check  the  values  in 
the  legal  and  key  fields  only  when  you  give  a  command  which  would 
change  the  contents  of  the  data  base. 

Once  you  understand  the  layout  of  the  screen,  you  will  need 
to  be  able  to  move  the  display's  cursor  (the  blinking  white  or 
black  box  or  underbar)  from  field  to  field  in  order  to  make 
changes.  The  TAB  key  is  the  primary  means  of  doing  this;  hitting 
it  jumps  the  cursor  to  the  next  field  (to  the  right,  or  to  the 
first  one  on  the  next  line) .  Within  a  field  the  BACKSPACE  key 
will  perform  its  normal  function,  as  will  the  space  bar. 

The  cursor  control  keys  on  your  keyboard  (arrow  keys)  will 
not  work  as  they  usually  do.  However,  if  you  are  using  an  HP 
terminal,  you  will  notice  that  the  function  keys  are  labeled  as 
performing  actions  like  "left"  and  "up".  The  function  keys  can 
be  used  in  place  of  the  cursor  control  keys.  If  you  are  not 
using  an  HP  terminal,  control-R  moves  the  cursor  right  one  space. 
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control-L  moves  it  left,  control-U  moves  it  to  the  next  field  in 
the  upward  direction,  control-D  moves  it  down,  and  control-Z  will 
redraw  the  display  if  it  becomes  garbled  somehow. 


7.6.2  Adding, 

To  add  a  new  record  to  the  data  base,  just  fill  in  all  the 
fields  on  the  screen  with  the  proper  values,  put  the  "A"  command 
into  the  COMMAND  field,  and  press  the  return  key.  The  DBU  will 
validate  the  data  and  do  the  addition.  If  the  data  does  not  pass 
the  validation  check  the  DBU  will  tell  you  why.  You  can  make 
validation  more  likely  by  using  the  ESC  +/“  commands  to  set  legal 
field  values  rather  than  trying  to  set  them  from  memory. 


7  .6  .3  flildlng-£,dXd 

Often  you  will  want  the  DBD  to  display  the  field  values  of 
a  particular  data  record,  either  for  your  inspection  or  so  you 
can  modify  them.  There  are  two  basic  ways  of  doing  this.  First, 
you  can  use  the  "N"  (next-record)  command  to  look  through  the 
underlying  data  relation  one  record  at  a  time  until  you  come  to 
the  one  you  are  interested  in.  This  is  fine  if  the  record  is 
near  the  top  in  the  sort  ordering  (records  are  displayed  in  the 
sort  order  of  the  key  fields) ,  but  quite  tedious  if  it  is  neces¬ 
sary  to  look  through  hundreds  to  find  one. 


The  alternative  is  the  "S"  (search)  command.  To  use  it, 
take  the  following  steps: 

1)  Give  the  "K"  (clear)  command  to  erase  all  the  fields  on 
the  screen.  It  is  important  not  to  omit  this  step,  as 
it  is  the  only  way  of  erasing  the  entry_by  and 
entry_date  fields  which  appear  on  most  screens, 

2)  Fill  in  selected  fields  with  "target"  values,  values 
which  the  record  you  are  looking  for  must  match,  if  a 
field  is  of  the  numeric  or  date  variety  the  DBU  will 
demand  that  records  match  the  value  you  specify 
exactly.  If  it  is  an  alphanumeric  field,  the  DBU  will 
demand  only  that  there  be  a  match  on  the  characters  you 
specify.  Suppose  you  are  looking  for  schedules  for  the 
DDG-51  class;  you  should  put  "DDG-51"  in  the  class  field 
on  the  given  schedule  screen  and  give  the  "S"  command. 
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But  if  you  were  interested  in  schedules  for  any  DDG 
classf  you  could  just  type  "DDG"  in  the  class  field  and 
the  DBO  would  return  records  with  any  of  DDG-2,  DDG-51, 
etc.  in  their  class  field.  However,  if  you  put  a  number 
in  the  hull  field  (which  is  numeric) ,  only  records  with 
an  exact  match  on  that  number  will  be  returned  (”1000” 
would  not  be  returned  in  response  to  a  specification  of 
”1”)  . 

The  more  fields  you  fill  in,  the  more  precise  your 
targeting  will  be.  However,  if  you  make  a  mistake  in 
specifying  a  value,  the  DBU  may  claim  that  it  cannot 
find  a  match  (and  it  truly  can't),  when  what  you  are 
really  looking  for  does  in  fact  exist.  Thus,  if  you  are 
unsure  about  a  value,  leave  that  field  blank. 

3)  Put  the  ”S”  command  in  the  command  field  and  hit  return. 
The  DBU  will  conduct  the  search  and  place  the  first 
matching  record  it  finds  onto  the  display.  If  there  are 
additional  matching  records,  you  can  look  through  them 
by  giving  the  ”N”  command  in  the  usual  way. 

4)  When  you  are  through  with  a  given  search  and  want  to 
”undo”  it,  you  may  either  specify  a  new  search  (using 
the  K  and  S  commands),  or  you  can  clear  all  searches  and 
return  to  the  beginning  of  the  file  by  giving  the  ”B” 
command. 

In  addition  to  the  search  capability,  there  is  also  a  more 
general  inspection-mode  control  capability.  As  noted  above,  most 
central  data  base  relations  can  hold  a  history  of  records  for  a 
given  data  item.  The  DATADATE  field  is  part  of  the  unique  key 
field  set  for  these  relations;  when  new  data  come  in  and  an  up¬ 
date  is  required,  it  can  be  added  with  a  later  data  date  instead 
of  being  written  over  the  record  that  is  out  of  date.  This  makes 
it  possible  to  perform  reconstructions,  but  the  presence  of  many 
records  for  each  item  can  be  a  hindrance  for  day-to-day  opera¬ 
tions,  when  generally  only  the  latest  data  is  of  interest. 


A  similar  problem  revolves  around  the  distinction  between 
actual  and  projected  data.  For  example,  the  current  SCN  job 
schedule  relation  has  a  DATETYPE  field,  in  which  the  nature  of  a 
data  record  can  be  specified.  For  query  purposes,  often  only 
actual  or  only  projected  data  will  be  of  interest. 
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The  nature  o£  the  records  which  the  "N*  or  "S”  commands 
offer  up  is  determined  by  the  DBU's  inspect-mode  setting.  The 
current  setting  is  shown  in  the  middle  of  the  very  top  line  of 
the  display  for  every  data  screen  (just  to  the  left  of  the  cur¬ 
rent  scenario  name) .  The  setting  will  take  the  form  of  "LATEST 
PROJECTED  DATES",  "ALL  DATES",  "LATEST  DATA",  etc.,  depending  on 
the  nature  of  the  screen.  To  change  the  setting,  give  the  "L" 
command.  You  will  be  prompted  for  a  data  date  restriction  set¬ 
ting  (LATEST  or  ALL)  and  a  date  type  restriction  setting  (ACTUAL, 
PROJECTED,  or  ALL) .  If  you  choose  LATEST,  only  the  records  with 
the  most-current  data  date  for  each  item  will  be  returned  by 
Searches  and  Nexts.  ALL  will  cause  all  records  to  be  returned. 

Note  that  if  the  date  type  setting  is  ALL  and  the  data  date 
restriction  LATEST  (the  mode  setting  display  will  read  "LATEST 
DATES"),  and  there  are  both  actual  and  projected  records  for  a 
given  item  (e.g.  ship),  the  DBU  will  display  only  the  record  with 
the  latest  data  date,  not  both  the  latest  actual  and  the  latest 
projected  one. 

7.6.4  Chanaihg  a.  Data  Base  Regoxd 

Having  retrieved  a  record  onto  the  screen,  you  are  free  to 
change  its  values.  There  arw  two  ways  of  posting  your  changes  to 
the  data  base.  The  first,  giving  the  "N"  (modify)  command,  will 
cause  the  DBU  to  replace  the  original  record  with  one  with  the 
values  now  displayed.  Modification  can  work  only  if.you_have  not 
changed  any  key  field  values,  because  the  DBU  must  use  these 
values  to  find  its  way  back  to  the  original  record.  If  you  have 
changed  key  field  values  other  than  the  DATADATE  field,  you 
should  use  the  A  (add)  command,  since  you  have  effectively 
created  a  new  data  item. 


If  you  wish  to  retain  the  old  data  record  for  historical  or 
audit-trail  purposes,  you  can  still  put  the  altered  record  into 
the  data  base  using  the  "U"  (update)  command.  This  is  similar  to 
an  add  command  in  that  it  adds  a  new  record  to  the  relation 


without  disturbing  the  one  you  retrieved,  but  differs  in  the  val¬ 
idation  checks  performed.  Update  insists  that  there  already  be  a 
record  in  the  relation  with  key  field  values  identical  to  all 
those  showing  on  the  screen  EXCEPT  for  DATADATE,  which  you  must 
have  assigned  a  new  value  to. 

As  a  general  rule,  most  data  entry  changes  should  be  posted 
using  Update,  while  corrections  of  data  entry  errors  should  be 
posted  using  Modify. 

7.6.5  jfiigfeing  a^Jata. Regard 

You  can  remove  a  data  record  from  the  data  base,  after 
having  retrieved  it  onto  the  screen,  by  issuing  the  ”D”  command. 
Be  aware  that  this  can  lead  to  deletion  of  more  than  just  the 
record  you  see.  If  there  is  data  elsewhere  in  the  data  base 
which  is  "subsidiary”  to  it,  the  DBU  will  delete  that  as  well 
(after  prompting  you  for  approval  to  go  ahead) .  If,  for  example, 
you  ask  that  the  DOG-51  record  be  deleted  in  the  class  charac¬ 
teristics  screen,  this  is  tantamount  to  a  request  that  all  infor¬ 
mation  having  to  do  with  DDG-51's  be  flushed  from  your  scenario. 

Note  that  this  step  is  taken  only  when  you  are  deleting  the 
last  record  for  the  given  item.  If,  for  ex^unple,  you  are  only 
deleting  outdated  records  for  the  DDG-51  class,  leaving  at  least 
one  (say  the  most  current  one)  in  place,  then  no  wholesale  dele¬ 
tion  will  occur. 

7.6.6  yalidatioD 

Data  record  validation  occurs  whenever  you  give  the  "A", 

"M",  "U",  or  "V"  commands.  "V"  (verify)  performs  only  the 
validation,  allowing  you  to  fill  in  only  the  key  and  legal s 
fields  on  a  data  screen  and  then  see  if  they  will  be  approved 
before  you  go  on  to  fill  in  the  rest  of  the  fields. 

Three  types  of  vedidation  are  typically  performed.  First, 
the  DBU  checks  to  see  if  the  values  of  the  key  fields  (other  than 
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DATADATE)  which  you  have  filled  in  form  a  unique  set  for  your 
current  scenario.  They  must  be  unique  if  you  have  issued  the  "A" 
command  (i.e.  the  given  item  must  not  have  been  previously 
added) ,  and  must  NOT  be  unique  otherwise. 


Second,  a  check  is  made  to  make  sure  that  companion  data  is 
present  elsewhere  in  the  data  base.  This  is  called  a  "join 
check”,  because  it  ensures  that  you  will  be  able  to  make  joins 
among  relations  when  you  make  queries  using  RELATE.  The  DBU 
consults  the  join  requiranent  specifications  given  in  the 
filjoin.db  relation  in  the.  data  dictionary  in  deciding  what  to 
check.  An  example  would  be  the  checks  made  for  a  projected  SCN 
job  schedule  record:  a  match  would  be  required  on  the  class  name 
in  shdesc.miscj  and  on  the  yard  name  in  yardid. yards.  A  match  on 
class  and  job  type  in  the  ncjdat.descj  schedule  planning  factors 
relation  would  be  "recommended.” 


The  basic  principles  from  which  the  join  requirement  speci> 
fications  were  derived  are  as  follows: 

1)  All  values  in  a  OiASS  field  in  any  relation  must  have  a 
match  in  the  same  scenario  in  the  shlif e.misc j, 
shdesc.miscj,  and  vedcls.mnurel  relations. 

2)  All  values  in  a  YARD  field  in  any  relation  must  have  a 
match  in  the  same  scenario  in  the  yardid. yards  and 
valyds.mnurel  relations. 

3)  All  vedues  in  a  NCJOBT  field  in  any  relation  must  have  a 
match  in  ncjobt. legal s,  jobtyp. legal s,  and  in  the  same 
scenario  in  vlj  typ.mnurel. 

4)  All  values  in  a  REJOBT  field  in  any  relation  must  have  a 
match  in  rejobt. legal s,  jobtyp. legal s,  and  in  the  same 
scenario  in  vlj  typ.mnurel  and  vlrjob.mnurel. 

5)  The  set  of  values  for  the  SCENARIO, CLASS, HULL, COMNUM 
fields  in  any  record  in  the  deact.miscj  relation  must 
have  a  match  in  one  of  ncjodat.histj,  ncjodat.curr j ,  or 
ncjodat.proj j  (you  can't  retire  a  ship  that  was  never 
commissioned) . 

6)  The  set  of  values  for  the  SCENARIO, CLASS, NCJOBT  fields 
in  any  ncjodat.proj  j  record  should  have  a  match  in  the 
ncjdat.descj  relation  (there  should  be  schedule  planning 


factors  for  every  scheduled  SCN  job),  but  this  is  not  an 
absolute  requirement. 

7)  Every  record  in  a  relation  holding  comment  text  must  be 
associated  with  a  record  in  its  companion  data  relation, 
the  association  being  by  identical  values  in  all  the 
fields  forming  the  data  relation's  unique  key  field  set. 

7 .7  COMMENTING 

The  DBU  makes  it  possible  to  keep  notes  or  comments 
concerning  every  data  record  displayable  on  a  DBU  data  screen. 
Each  data  screen  has  an  associated  comment  screen  which  can  be 
called  up  by  giving  the  "C*  command.  The  comment  screen  displays 
(without  permitting  changes  to)  the  current  values  of  the  data 
screen's  unique  key  field  set,  and  provides  a  block  of  9  65~space 
lines  for  typing  of  textual  notes.  These  notes  are  saved  in  a 
comment  relation  associated  with  the  data  relation (s)  (meaning 
the  comment  relation  has  a  similar  name,  is  stored  in  the  same 
file  group,  and  has  the  same  unique  key  field  set  as  the  data 
relation,  with  the  addition  of  a  line  number  field) . 

Existing  comments  are  retrieved  automatically  for  the 
current  record  when  the  comment  screen  comes  up.  They  can  be 
modified  freely. 

The  DBU's  capacity  is  24  lines  of  comments  per  data  record, 
although  the  window  on  comment  screens  is  only  9  lines  long. 
Comment  screens  will  respond  to  the  "+"  and  paging  commands 
in  much  the  same  was  as  the  assigner  does,  allowing  you  to  peruse 
and  alter  long  comments  a  little  at  a  time. 

TWO  special  Escape  commands  are  available  to  support  com¬ 
ment  text  modification:  Escape  I  inserts  a  blank  line  into  the 
text  at  the  point  on  the  window  where  you  have  placed  the  cursor, 
while  Escape  D  deletes  the  line  at  the  current  cursor  position 
and  closes  up  the  text. 


The  update  mechanism  for  comments  differs  from  that  for 
ordinary  data  records.  The  ”A”,  "U",  and  "M*  commands  do  not 

operate  in  comment  screens - instead,  comment  text  is  retained  in 

the  DBU*  s  menory  when  you  return  to  the  data  screen  from  the 
comment  screen,  and  is  posted  to  the  comment  relation  when  you 
finish  with  the  data  record  showing  on  the  data  screen. 
"Finishing”  can  be  triggered  by  any  command  which  would  show 
another  data  record,  or  any  command  which  would  post  the  data 
record  to  its  relation. 

There  are  a  few  subtle  restrictions  on  this  capability. 

The  first  is-  that  changes  to  key  field  v£dues  will  cause  any 
comment  changes  you  have  made  to  be  lost  (much  like  the  regular 
Modify  command,  the  DBU  will  not  be  able  to  find  the  original 
comments  in  order  to  change  them) .  For  this  reason,  you  should 
always  fill  in  all  key  fields  before  calling  up  the  comment 
screen,  and  should  use  the  Verify  command  to  make  sure  they  will 
be  accepted. 

7 .8  PRINTING 

The  DBU  provides  a  data  printing  service  which  is  acces¬ 
sible  from  any  data  screen  by  issuance  of  the  ”P”  command.  Ihe 
screen  which  responds  will  list  (and  execute  at  your  command)  any 
special  report  generators  which  have  been  designed  for  the  given 
data  screen's  underlying  relation.  Often  there  will  not  be  any 
of  these,  but  the  screen  edso  will  cause  a  formatted  PRINT 
command  to  be  issued  for  the  contents  of  the  relation,  with  the 
contents  being  restricted  both  by  any  Search  command  you  have 
executed  and  by  the  display  mode  subsystem's  setting.  Thus,  to 
get  a  printout  of  the  latest  actual  schedules  for  current 
destroyer  construction  jobs,  you  could  go  to  the  CURILNC_SKED 
screen,  set  the  Inspect  mode  to  LATEST  ACTUAL  DATES,  do  a  Search 
specifying  that  CLASS  field  values  must  begin  with  ”DD",  give  the 
”P”  command,  and  choose  option  1.  The  last  two  steps  can  be 
given  in  shorter  form  by  giving  the  command  ”P1”  in  the  data 


screen 


The  print  screen  asks  which  printer  to  send  the  results  to, 
offering  the  SEA  90  daisy  wheel,  SEA  90  dot  matrix,  PMS  392  line 
printer,  and  your  terminal  as  options. 

7.9  MISCELLANEOUS  SEKVICES 

An  MPE  command  can  be  given  at  any  time  by  giving  the 
command  and  responding  to  the  resulting  prompt.  The  TDP  and  HP 
editors  can  be  used  by  giving  the  ”T"  or  "TH”  commands, 
respectively. 

A  specieUL  service,  schedule  data  recalculation,  is  avail¬ 
able  only  in  the  PROJ.NCLSKED  screen.  It  is  designed  to  allow 
quick  recomputation  of  schedule  dates  from  a  new  basis  date  using 
the  schedule  planning  factors  for  the  current  scenario  stored  in 
the  ncjdat.descj  relation.  To  use  the  service,  type  a  date  into 
any  milestone  date  field  on  the  screen,  leave  the  cursor  in  that 
field,  and  give  the  Escape  R  command.  The  DBU  will  find  the 
appropriate  estimate  of  intervals  between  milestones  in  ncjdat 
using  the  values  of  the  class,  yard,  job  type,  and  series  type 
fields  on  the  screen  (note  that  if  no  exact  match  is  found  on  the 
yard  name,  intervals  for  yard  "ANY”  will  be  used  for  the  given 
job  if  found  in  ncjdat)  and  will  then  ccxnpute  a  complete  set  of 
milestones  just  as  the  assigner  would. 


8.0 


The  assignee  is  a  tool  for  creating  and  changing  sets  of 
projected  ship  construction  schedules.  It  works  by  reading  your 
scenario's  schedules  from  the  data  base,  converting  them  into  a 
shipyard-assignments  format,  allowing  you  to  make  changes  to  the 
assignments,  and  then  converting  them  back  into  schedules  again. 

This  section  will  describe  how  to  use  the  assigner  and  to 
some  extent  how  it  works.  With  regard  to  the  latter,  it  is 
important  to  understand  the  methods  the  assigner  uses  to  create 
new  schedules  in  order  to  make  full  use  of  its  capabilities. 

To  execute  the  assigner,  move  to  the  assigner  choice  menu 
in  the  Command  System  and  choose  option  2. 

8 .1  SCHEDULES 

For  the  assigner* s  purposes,  a  schedule  is  a  record  in  one 
of  six  central  data  base  relations  (files  nejodat  and  rejodat  in 
each  of  groups  histj,  currj,  and  projj)  which  describes  the 
nature  and  timing  of  a  shipyard  job.  The  "nejodat"  relations  are 
for  jobs  of  the  new  construction  variety,  defined  as  any  which 
add  ships  to  the  Navy  force  level  under  a  new  class/hull  number 
designation  (thus  including  new  construction,  conversion,  and 
reactivation),  and  edso  including  commercied  new  construction  and 
conversion.  The  "rejodat”  relations  are  for  jobs  of  the  repair 
variety,  defined  as  being  done  on  a  ship  in  the  active  force 
(thus  including  SLEPs  and  nuclear  refuels  as  well  as  RO's,  etc.). 
The  three  groups  are  for  historical  jobs  (those  completed) ,  cur¬ 
rent  jobs  (those  awarded  but  not  yet  delivered),  and  projected 
jobs  (those  not  yet  awarded) . 

The  display  produced  by  the  assigner  can  contain  jobs  from 
any  of  the  six  relations,  but  the  assigner  is  capable  of  creating 
schedules  only  for  projected  new  cont ruction- type  jobs  (i.e.  in 
the  nejodat. projj  relation). 
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Figure  8-1  shows  some  schedule  records  from  ncjodat.proj j . 
Figure  8-2  expands  the  first  record  shown  in  Figure  8-1  into  e. 
more  readable  format.  It  is  important  to  understand  the  struc¬ 
ture  of  this  record  if  you  are  to  gain  a  full  understanding  of 
assignor  operations.  Its  fields  are: 

1)  $LINE:  The  ID  number  which  RELATE  assigns  to  each 
record. 

2)  SCENARIO:  The  name  of  the  scenario  the  schedule  belongs 
to  (remember  that  other  scenarios  might  use  the  record 
indirectly) . 

3)  CLASS:  The  name  of  the  ship  class  the  job  will  be  dene 
for.  A  record  for  this  scenario  with  this  class  name 
must  appear  in  shdesc.miscj,  shlife.miscj,  and 
valcls.mnurel  for  data  base  internal  consistency. 

4)  HULL:  The  hull  number  of  the  ship  the  job  will  be  done 
on.  This  is  a  numeric  variable. 

5)  COMNUM:  Commissioning  number.  If  a  ship  has  been 
mothballed  and  then  reactivated,  it  will  have  more  than 
one  job  record  in  the  three  nejodat. relations.  The 
initial  construction  record  will  have  a  COMNUM  field 
value  of  1,  while  the  first  reactivation  will  have  a 
value  of  2,  the  second  a  value  of  three,  etc.  In 
combination  with  CLASS  and  HULL,  this  field  uniquely 
identifies  the  job  for  force  structure  impact  purposes. 

6)  YARD:  Name  of  the  shipyard  the  job  is  to  be  performed 
at.  A  record  for  this  scenario  with  this  name  must 
appear  in  yardid. yards  and  valyds.mnurel. 

7)  NCJOBT:  "New  Construction  JOB  Type" - a  code  indicating 

the  type  of  job  to  be  performed.  The  code  must  be  on 
the  list  of  legal  codes  in  ncjobt.legals  and 

jobtyp. legal s. 

8)  JSTYP:  "Job  Series  TYPe" - a  code  indicating  whether 

the  job  is  of  the  lead,  first  follow,  etc.  variety.  The 
code  must  be  on  the  list  of  legal  codes  in  jstyp. legal s. 

9)  CUSTOMER:  Name  of  the  organization  the  job  is  being 
done  for.  Almost  always  "USN". 

10)  SHIFNAME:  If  known,  the  full  name  of  the  ship. 

11)  CMETBD:  Construction  method  to  be  used.  The  code 
which  appears  here  must  appear  on  the  list  of  legal 
codes  in  cmethd. legals. 
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Figure  8-1.  Semple  Schedules  From  Ncjodat.proj j  Relation 


$LINE  SCENARIO  CLASS  HUH.  a>MNUM  YARD  NCJCBT  JSTYP  CUSTDMEll  SHIRIAME 
QtEnBD  APETOP 

mPKD  START  KEEL  LAUNCH  DELIVERY  QOMMISSHlt  DAYSAEKD  ASNGRIXR 

DATADATE  DATASOQRCE  EMTRYBY  ENTRYDATE  AUTO 
PROGVARl  EROGVAR2  SUBRELUHAP 


NGJCBT  JSTYP  CUSTOMER  SHIRIAME 


334  DEMO  LSD-41  42  1  AVCNDALE  NENOCN  GRDEOL  USN 

MDDULZ  10/01/1985 

11/01/1985  11/01/1986  5/01/1987  1/01/1989  5/01/1990  6/01/1990 

10/2^1984  908/SHAPM  MARK  10/2^1984  YES 

42  0  0 

335  DEMO  LSD-41  43  1  AVCNDALE  NEMGCN  CRDEOL  USN 

MDDULZ  10/01/1984 

11/30/1984  6/30/1986  1/30/1989 

9/01/1984  90^SHAPM  DBA  9/25/1984  YES 

41  1  0 

336  DEMO  LSD-41  44  1  AVCNDALE  NENOON  CRDEOL  USN 

MDDULZ  10/01/1985 

11/01/, 985  7/02/1987  1/02/1988  9/02/1989  1/02/1991  2/02/1991 

10/2^1984  90a/SHAEM  MARK  10/2^1984  YES 

43  0  0 

337  DEMD  ISD-41  45  1  AVCNDALE  NENOCN  CRDEOL  USN 

MDDULZ  10/01/1986 

11/01/1986  3/01/1988  9/01/1988  5/01/1990  9/01/1991  10/01/1991 

10/2^1984  90E^SAPM  MARK  10/2G/1984  YES 

44  0  0 

338  DEMD  ISD-49  49  1  AVCNDALE  NENOCN  LEAD  USN 

MDDULZ  10/01/1987 

11/01/1987  11/01/1988  7/01/1989  6/01/1991  6/01/1993  7/01/1993 

10/2E/1984  90e/SHAFM  MARK  10/28/1984  YES 

49  1  0 

339  DEMD  ISD-49  50  1  AVCNDALE  NENOCN  CRDEOL  USN 

MDDULZ  10/01/1987 

11/01/1987  5/02/1989  1/0^1990  12/02/1991  12'02/1993  1/02/1994 

10/28/1984  908/SAPM  MARK  10/28/1984  YES 

50  0  0 


0  57553221 


0  57553221 


0  57553221 


0  57553222 


0  57553222 
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Figure  8-2.  A  Single  Sample  Schedule 


FIELENAME 

VALUE 

$L1ME 

334 

SCENARIO 

EENO 

CLASS 

LSD-41 

BOLL 

42 

CDMNOM 

1 

YARD 

AE/CNDALE 

MCJGBT 

NMCDN 

JSTYP 

CBDFCL 

OJSIDHER 

USN 

SBIFNAME 

OlETHD 

MODULZ 

AFFROP 

10/00/1985 

AWARD 

lVOl/1985 

SWT 

1V0V1986 

(fCTT. 

5/01/1987 

LAUNCH 

1/00/1989 

DELIVERY 

5/01/1990 

CDM4ISSI0N 

e/OO/1990 

DAYSACDED 

0 

AaXIUDER 

57553221 

DATADATE 

10/2^1984 

DAOASamCE 

908/SHAH1 

eotklby 

NARK 

eotkcdaoe 

10/26/1984 

AinDM3) 

YES 

FROG/ARl 

0 

£«3SVAR2 

0 

SlEREUJHkP 

0 

12)  APPROP:  Projected  date  of  appropriation  of  the  ship 
(job)  . 

13)  AWARD:  Projected  award  date. 

14)  START:  Projected  start  date. 

15)  KEEL:  Projected  date  the  keel  will  be  le.ic'.,  cr  for 
land-level  facilities,  date  of  first  major  assembly  area 
occupancy.  Date  of  drydocking  for  reactivations  and 
conversions. 

16)  LAUNCH:  Date  the  ship  will  go  into  the  water. 

17)  DELIVERY:  Date  the  ship  will  be  delivered  to  the 
customer. 

18)  COMMISSION:  Date  the  ship  will  be  commissioned.  Dees 
not  apply  to  commercial  jobs. 

19)  DAYSADDED:  Days  added  to  the  ship's  basic  service  life 
by  the  job.  This  will  be  0  for  new  construction  jobs, 
but  reactivations  may  offer  some  of  the  life-extension 
benefits  of  a  SLEP. 

20)  ASNORDER:  A  variable  used  by  the  assigner  for 
sort-ordering,  of  no  interest  to  you. 

21)  DATADATE:  Date  as  of  which  the  record's  data  is  valid. 
If  the  record  is  generated  by  the  assigner,  this  will  be 
the  same  as  the  entry  date. 

22)  DATASOURCE:  Note  of  the  source  of  the  data. 

23)  ENTRY.BY:  User  name  of  the  person  who  entered  the  data 
in  the  record. 

24)  ENTRY.DATE:  Date  the  record  was  added  to  or  updated  in 
the  relation. 

25)  AUTOMOD:  "Yes"  if  the  assigner  may  chance  the  contents 
of  the  record  during  its  update  step.  Setting  this 
value  to  "no"  after  making  changes  to  the  record  in  the 
DBU  ensures  that  your  changes  will  not  be  thrown  out  by 
a  subsequent  assigner  run. 

26)  PROGVARl:  Used  by  the  assigner  for  computations. 

27)  PROGVAR2:  Used  by  the  assigner  for  computations, 

28)  SUBRELUMAP:  Indicates  to  the  assigner  and  DBU  which 
relations  subsidiary  to  ncjodat.proj j  have  records 
associated  with  this  record.  The  value  will  be  0  if 
there  are  none. 
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From  the  point  of  view  of  identification  of  the  nature  of 
the  record's  jobr  the  most  important  fields  are  SCENARIO,  CLASS, 
NCJOBT,  and  JSTYP.  Prom  the  point  of  view  of  contents,  the 
milestone  date  fields  are  of  most  Interest.  The  assicner  display 
contains  the  values  of  all  the  identification  fields,  and  of  one 
of  the  milestone  fields,  in  some  form  for  every  job  it  shows. 

8.2  READING  THE  ASSIGNEE  DISPLAY 

When  you  execute  the  assigner,  it  will  first  "load"  all  the 
relevant  schedules  for  ycur  scenario,  meaning  it  will  read  them 
and  convert  them  into  the  assignments  format.  It  will  then  type 
the  first  page  of  assignments  onto  your  terminal  display,  which 
will  look  something  like  Figure  8-3. 

A  shipyard  assignment  is  a  ship-job  projected  fcr  perfor¬ 
mance  at  a  given  yard  in  a  given  period.  It  is  thus  equivalent 
to  a  schedule,  but  it  appears  on  the  assigner  display  as  a 
numeric  value  in  one  of  the  display  cells.  For  example,  the  top 
left  cell  shown  in  Figure  8-3  indicates  that  there  are  two 
LSD-41 's  assigned  to  the  Avondale  yard. 

The  display  is  organized  as  a  table  of  rows  and  columns: 
each  rev  has  the  assignments  for  jobs  of  a  particular  typv:  to  be 
done  on  ships  of  a  particular  class  at  a  given  yard.  Each  ccjirr 
indicates  the  number  of  jobs  to  be  performed  in  each  period.  The 
periods  can  be  in  units  of  days,  weeks,  months,  quarters,  calen¬ 
dar  years,  or  fiscal  years.  The  units  fcr  the  sample  are  fiscal 
years,  as  indicated  by  the  "Time  in:"  label  at  the  top  right  of 
the  page.  There  are  two  rows  of  columns  headings:  the  top  one 
just  counts  the  number  of  periods  starting  at  1,  while  the  one 
below  it  gives  whatever  period  labels  make  sense,  here  the  last 
two  digits  of  the  fiscal  year  the  column  represents. 

The  cell  values  are  based  on  the  projected  number  of 
occurrences  of  a  basis  milestone  date,  which  can  be  any  one  of 
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Figure  8-3 .  A  lypical  Assigner  Display  Bage 
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appropriation,  award,  start,  keel,  launch,  or  delivery.  The  page 
shown  is  using  award  as  its  basis  milestone,  so  the  assignment  of 
two  LSD-41 's  in  fiscal  1986  indicates  that  two  are  projected  to 
be  awarded  to  Avondale  that  year. 

It  is  fairly  evident  which  yard  and  ship  class  each  row  is 
for,  but  how  do  you  tell  the  job  type  and  job  series  type? 

Notice  the  bottom  row  of  assignments  in  the  sample,  those  for 
AO-1 87 's  at  General  Dynamics'  Quincy  yard.  There  is  a  "c"  in  the 
last  column  of  the  class  name  area.  This  column  holds  a  single 
character  code  which  represents  the  job  type.  The  ”c"  stands  for 
"conversion",  so  the  AO-1 87 's  are  to  be  converted  at  Quincy.  If 
there  is  a  blank  or  an  "n”,  that  indicates  new  construction  jobs. 
Other  codes  are  "r"  for  reactivation  and  "s"  for  SLEP.  A  com¬ 
plete  list  of  codes  can  be  obtained  from  the  assigner's  on-line 
help. 


The  same  yard,  ship  class,  and  job  type  will  apply  to  all 
the  ships  assigned  in  a  given  row,  but  job  series  type  must  be 
individualized  by  ship.  This  is  done  with  the  single-character 
codes  appearing  in  the  table's  cells.  Notice  the  "L"  in  the 

fiscal  1988  column  for  LSD-49  new  construction  at  Avondale - this 

indicates  that  one  of  the  two  ships  awarded  in  that  year  will  be 
a  lead  ship.  Other  codes  are  ”F"  for  first  follows  and  "Y"  for 
yard  leads.  No  code  indicates  an  ordinary  follow. 

Notice  the  page  number  shown  on  the  top  line  of  the  sample. 
The  assignor  display  can  be  thought  of  as  a  window  on  a  huge 
worksheet,  with  up  to  500  rows  and  260  columns  (you  can  make 
assignments  for  65  years  in  quarters,  20  years  in  months,  five 
years  in  weeks,  or  2/3  year  in  days).  Up  to  twenty  columns  can 
fit  on  the  display  at  a  time.  In  the  sample,  the  total  period  of 
interest  is  only  nine  years,  so  the  columns  required  fill  up  less 
than  a  single  page. 
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Moving  the  window  around  on  the  worksheet  is  known  as 
"paging";  you  can  page  right  or  left,  and  up  or  down,  nie  page 
number  label  indicates  both  the  horizontal  and  the  vertical 
position  of  the  current  page.  The  numeric  part  indicates  the 
vertical  page,  while  the  letter  indicates  the  horizontal  page. 

The  row  and  column  totals  which  appear  are  the  totals  for 
the  complete  sheet,  not  just  the  page  displayed;  likewise  the 
grand  total  at  the  bottom  right  gives  the  total  number  of  assign¬ 
ments  loaded.  The  totals  at  the  bottom  left  (just  to  the  left  of 
the  "TOTALS"  label)  are  the  number  of  yards  and  the  number  of 
assignments  rows,  respectively.  Notice  that  each  yard  is  labeled 
with  a  number;  you  can  tell  you  are  on  the  last  vertical  page  if 
the  number  of  the  last  yard  is  the  same  as  the  total  number  of 
yards. 


8.3  ASSIGNER  COMMANDS  FOR  WORKING  WITH  THE  TABLE 

Figure  8-4  summarizes  the  available  assigner  commands  (it 
is  part  of  the  assigner 's  on-line  help,  and  so  can  be  referred  to 
any  time  you  are  running  the  assigner) .  The  commands  fall  into 
three  categories:  those  for  paging,  those  for  changing  the  con¬ 
tents  of  the  table,  and  miscellaneous  service  commands. 

The  assigner  uses  the  same  line-oriented  prompt-and- 
response  means  of  obtaining  your  commands  as  the  Command  System 
does.  Ihe  "(?«help)  >"  appearing  at  the  bottom  of  Figure  8-3  is 
its  prompt.  It  will  only  accept  one  command  per  occurrence  of 
the  prompt. 


8.3.1 


To  see  the  next  page  to  the  right,  give  the  ">"  command. 

To  see  the  farthest  right-hand  page,  use  ">>".  The  "<"  and  "<<" 
commands  perform  similar  functions  for  movement  in  the  leftward 
direction. 


To  see  the  next  page  down,  use  "■<■".  The  last  page  can  be 
obtained  by  issuing  "++".  Upward  paging  is  accomplished  with  "-" 
and 
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8.3.2  Editing  Commands 

The  commands  covered  in  this  section  are  for  addition, 
modification,  and  deletion  of  assignments.  The  basic  commands 
are  "A"  for  addition,  "I"  for  insertion,  "D"  for  deletion,  and 
”M”  for  modification. 

Most  of  these  commands  require  you  to  specify  which  assign¬ 
ment  row  or  shipyard  you  want  then  to  act  on.  For  example,  if 
you  wanted  to  modify  the  OG-47  assignments  at  Bath  in  Figure  8-3, 
you  would  give  the  command  "M  2.1",  meaning  that  you  want  to 
modify  the  first  row  in  the  second  yard.  You  use  the  numbers 
with  which  each  row  and  yard  are  labeled  to  indicate  your 
selection.  Note  that  these  numbers  can  change  as  you  add  new 
assignments,  so  be  sure  to  look  at  the  display  before  giving  a 
command. 

When  you  ask  to  add  assignments  for  a  new  yard  you  will  be 
given  prompts  which  resemble  the  following: 

Give  yard  name  please  (Type  to  cancel)  >  TODD  LA 
Make  new  assignment  for  yard  #13,  TODD  LA 
Period:  1123456789 
Shipclass  T|86  87  88  89  90  91  92  93  94 


DDG-51  FI  2  2  2 

You  are  expected  to  type  the  class  neune  under  the  first  section 
of  dots.  The  appropriate  job  ^pe  code  must  be  placed  at  the 
position  of  the  last  dot  if  the  job  is  not  of  the  new  con¬ 
struction  variety.  Then  type  the  number  of  assignments  in  each 
period  (including  series  type  codes,  if  any)  in  the  pattern 
provided.  You  need  not  place  each  assignment  at  the  position  of 
the  right-hand  dot  for  each  cell,  but  it  is  important  not  to  put 
any  numbers  where  there  are  blanks  in  the  prompt.  Keep  in  mind 


that  if  you  make  a  mistake  you  can  always  correct  it  using  the 
Modify  command. 


-  Addition  - 

To  add  an  assignments  row  to  a  yard  which  has  none,  give 
the  "A”  command  all  by  itself.  You  will  be  prompted  for  the  name 
of  the  yard  and  then  for  the  assignments. 

To  add  to  a  yard  which  already  has  some,  you  may  use  either 
"A  #",  where  is  the  yard's  number,  or  "I  #.#",  where  #.# 
gives  the  yard  and  row  within  the  yard  you  want  the  new  row  to 
precede  (thus  you  can  control  the  orde  of  display  of  class-jobs 
within  a  yard) . 


- Modification - 

To  modify  a  row  of  assignments  you  must  specify  the  yard 
number  and  row  within  the  yard  to  be  changed  (M  #.#).  A  slightly 
different  prompt  than  the  one  shown  above  will  be  given: 

Modify  assignment  to  yard  BIM 

(Blanks  denote  no  change;  use  zero  for  assignment  deletion) 
Period:  1123456789 
Shipclass  T|86  87  88  89  90  91  92  93  94 
1  CG-47  11111 

. 2 

The  current  values  will  be  shown.  You  do  not  need  to  retype  the 
whole  line  to  make  changes;  instead,  just  space  over  under  the 
cells  to  be  changed  and  place  the  new  values  there. 

You  can  change  the  names  of  yards  or  class-jobs  using  the 
"MM"  (Modify-Name)  command.  If  you  specify  only  a  yard  number  (M 
*)  then  you  will  be  asked  for  the  name  of  the  yard  those  assign- 
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ments  should  be  switched  to;  if  you  specify  both  a  yard  and  row 
number  (M  #.#)  then  you  will  be  prompted  for  a  new  class  name  and 
job  type  code. 


-  Deletion  - 

To  delete  all  the  assignments  for  a  given  yardr  give  the  "D 
t”  command,  where  **"  is  the  yard  number.  To  delete  only  a  given 
row  within  a  yard,  use  *D  #.#*. 

—  Moving  Assignments  Around  on  the  Page  - 

You  can  change  the  order  in  which  assignments  appear  on  the 
display  page  through  use  of  the  R  (relocate)  command.  Its  most 
general  form  is  ”R  s.r^t.r",  where  ”s.r”  is  the  current  yard  and 
row  number,  and  t.r  is  the  yard  and  row  number  you  would  like  the 
row  to  precede. 


—  Copying  Assignments  — - 

You  can  make  a  copy  of  a  given  row  of  assignments  and  place 
it  under  whatever  yard  and  class- job  name  you  please.  The  syntax 
of  the  RC  command  (relocate-copy)  i?  just  like  that  for  the 
Relocate  command  (RC  s.r,t.r).  You  will  be  asked  for  the  new 
class  name  and  job  type  code  after  giving  the  command. 

8.3.3  Miacellaneous  Service  Commands 

The  assigner's  service  commands  support  the  usual  set  of 
"housekeeping”  functions.  Help  can  be  obtained  with  ”?",  which 
will  bring  up  a  menu  describing  the  assigner's  extensive  on-line 
help.  Make  sure  to  look  at  this  menu  the  first  time  you  run  the 
assigner  so  you  will  know  what  information  is  available. 

The  command  will  cause  the  current  page  to  be  re-typed 
onto  the  display.  Unless  you  have  executed  the  assigner  in 
"auto-refresh  mode"  (more  on  this  in  a  moment),  you  will  need  to 
give  the  "&"  command  after  giving  the  commands  tor  changing  to  a 
different  page. 
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The  ”0”  command  terminates  your  editing  session  and  starts 
the  assignor's  schedule  creation  and  update  pass.  The  "H”  com¬ 
mand  allows  you  to  temporarily  exit  back  to  the  Command  System, 
leaving  your  editing  session  on  hold.  You  must  come  back  and 
complete  the  session  by  giving  the  Q  command  if  any  changes  you 
have  made  are  to  be  saved.  Note  that  changes  you  make  to 
assignor  parameters  will  have  no  effect  on  an  editing  session 
that  is  in  progress. 

The  ”P"  command  prints  the  contents  of  all  assignor  display 
pages,  sending  the  output  to  the  printer  specified  in  the  User 
Environment  Parcuneter  menu  for  your  current  scenario.  The  format 
of  the  output  will  be  one  display  page  per  physical  page. 

8.4  ASSIGNER  MODE  CONTROL  OPTIONS 

You  can  vary  a  number  of  the  assignor's  characteristics, 
including  the  time  span  and  time  units  used  on  the  display  page, 
the  nature  of  the  assignments  loaded  from  the  schedule  data  base, 
and  the  algorithms  used  to  create  new  schedules  during  the  update 
pass.  You  exercise  this  control  by  choosing  values  on  the  Com¬ 
mand  ^stem's  Assignor  Parameter  Menu,  a  sample  of  which  is  shown 
in  Figure  8-5. 


The  parameters  and  their  effects  are: 

1}  TIME  UNITS:  This  setting  determines  the  span  of  time 
represented  by  each  display  page  column.  The  smaller 
this  span,  the  more  precisely  you  specify  the  value  of  a 
given  ship's  basis  date  when  you  place  its  assignment  in 
a  given  column. 

2)  STARTING  DATE:  The  first  date  of  interest  to  you  for 
the  next  assignor  run.  The  assignor  will  not  load 
schedules  with  a  basis  date  prior  to  this,  nor  will  it 
permit  you  to  make  assignments  prior  to  this  date. 

3)  ENDING  DATE:  In  combination  with  the  starting  date, 
determines  the  number  of  columns  (periods)  which  will 
appear  on  the  display  page.  You  will  not  see  nor  be 
able  to  make  assignments  after  this  date. 
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MAWAL  ASSIGNED 

TIME  UNIT 
STARTINS  DATE 
ENDING  DATE 

CMIDIDATE  SIP  YARDS  « 

CANDIDATE  SIP  OASSES 
CANDIDATE  JCB  TTPES 
DISPLAY  BASIS 
ADJUST  BASIS  > 

ADJUST  NUDE 
JOBS  EPOCH  OPnCN 
SIPOASS  SORT  ORDER  « 

SIPYARD  SORT  OBDER  > 

AUTO  REEHE5H  « 


MODULE  nnriALIZATICM  PJ«AA!ETERS 
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1/  V1980 
1V31/1999 
LIST 
LIST 
LIST 
ANARD 
START 
PROGRAM 
PROJ 
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INPUT  QRI^ 
OFF 


(FISCTRrCALYRrQTRrMGNTHrWEEK^DAY) 

(MVWXYYY) 

(MJVWYYYY) 

(AU/LIST) 

(ALI/LIST) 

(AU/LIST) 

(APIRQP, /MDr  START,  KEO.,  INCS ,  DELIV) 
(AFPROP,  AND,  START,  KEEL,  INCH,  DELIV) 
(NGNE,PIK]GRAM,QOMPLX--GnOUP) 
(AIIi,CDRE/If«OJ,PRQa) 

(ALPHABETIC,  INPUT  ORDER) 
(ALPHSETIC,  INPUT  CRDS) 

(CN,OPP) 


GOmAND 


4)  CANDIDATE  SHIP  YARDS  These  three  parameters  are 

5)  CANDIDATE  SHIP  CLASSES  gates  to  list  menus  which 

6)  CANDIDATE  JOB  TYPES  contain  complete  lists  of  all 
the  yard  names,  ship  class  names,  and  job  types  which 
are  known  to  your  current  scenario.  The  assigner  will 
only  load  assignments  for  those  yards,  classes,  and  job 
types  which  are  "turned  on”  in  these  list  menus,  and 
will  only  permit  you  to  make  assignments  to  those 
"turned  on".  Figure  8-6  contains  a  sample  of  the  job 
type  list  menu. 

These  lists  are  useful  for  restricting  the  volume  of 
assignments  you  will  have  to  work  with  in  a  given  run. 

If  you  are  mainly  interested  in  assignments  at  one  yard 
or  for  one  class  of  ship,  you  can  make  settings  in  these 
list  menus  which  will  limit  the  assigner  run  to  that 
yard  or  those  classes.  This  reduces  the  amount  of  time 
you  must  spend  paging  around  the  assigner  worksheet,  and 
also  reduces  the  overhead  time  spent  loading  and 
updating  schedules. 

7)  DISPLAY  BASIS:  The  milestone  date  you  are  implicitly 
specifying  when  you  place  an  assignment  in  a  given 
display  page  column,  i.e.  the  basis  date.  You  may 
choose  any  of  the  schedule  milestones  except  commission. 

8)  ADJUST  BASIS:  The  assigner 's  schedule  creation  logic 
can  be  instructed  to  construct  schedules  such  that 
assignments  are  spread  evenly  over  each  period  in  a 
given  yard.  Suppose  you  assign  four  DDG-51’s  to  be 
awarded  to  Ingalls  in  a  given  fiscal  year.  If  the 
setting  of  this  parameter  is  "START",  the  assigner  can 
create  four  schedules  in  which  the  start  dates  are 
spread  evenly  over  a  twelve  month  period.  If  "KEEL", 
the  keel  dates  will  be  so  spread,  and  etc. 

9}  ADJUST  MODE:  This  further  controls  the  schedule 

creation  logic.  You  can  turn  it  off  (i.e.  have  all  four 
jobs'  start  dates  be  on  the  same  day  in  the  above 
example)  by  choosing  "NONE";  date  spreading  can  be  done 
within  each  class  by  choosing  "PROGRAM";  or  it  can  be 
done  for  several  classesa  at  once  by  choosing 
”CX)MPLX_GROUP".  Each  class  is  specified  to  belong  to  a 
given  complexity  group  in  the  schedule  job  description 
relation  ncjdat.descj.  For  example,  if  you  choose 
C0MPL3L GROUP  and  there  are  four  DDG-51's  and  two  CG-47's 
awarded  to  Ingalls  in  the  same  year,  the  six  ships  will 
be  lumped  together  and  their  start  dates  spread  evenly 
over  a  twelve  month  period. 


(BOOSE  THE  SET  OF  VALID  JOBS  WHICH  MAY  BE  ASSIGNED 


1.  *  <X3NV 

2.  *  NEWGCN 

3.  *  REACT 


5.  *  REPAIR 

6.  *  SLEP 

7.  *  SLPCNV 


10)  JOBS  EPOGl  OPTION:  This  controls  the  loading  of 
assignments  from  the  schedule  relations.  To  see 
historical,  current,  and  projected  assignments  within 
your  specified  period  you  must  choose  "ALL";  to  see  only 
current  and  projected  choose  "CURR/PROJ";  and  to  see 
projected  only  choose  "PROJ".  Remember  that  any  editing 
changes  you  make  will  affect  only  projected  schedules. 
Substantial  time  can  be  saved  during  the  load  and  update 
phases  by  choosing  the  PROJ  option. 

11)  SHIPCLASS  SORT  ORDER:  This  controls  the  order  in  which 
class-job  assignments  rows  are  displayed  within  a  yard. 
The  choices  are  alphabetic  and  input-order,  the  latter 
meaning  the  order  in  which  you  added  them  to  each  yard 
(or  the  order  you  specified  using  the  Insert  and 
Relocate  commands) .  Note  that  once  you  have  chosen 
Alphabetic,  the  original  input  ordering  will  be  lost. 

12)  SHIPYARD  SORT  ORDER:  The  assigner  always  orders  yards 
alphabetically  on  the  display  at  this  time,  regardless 
of  this  setting. 

13)  AOTO  REFRESH;  If  "YES",  the  assigner  will  re-type  the 
current  display  page  after  execution  of  each  command. 

If  "NO",  you  must  give  the  "fit"  command  whenever  you  want 
the  display  updated,  including  after  issuance  of  paging 
commands.  If  you  are  operating  on  a  low-baud  rate 
terminail  a  choice  of  "NO"  is  likely  to  save  you  time, 
but  you  must  keep  more  careful  track  of  what  you  are 
doing  since  the  effect  of  each  command  is  not 
immediately  displayed. 

If  you  forget  the  parameter  settings  while  in  the  middle  of 
an  assigner  run  and  have  a  need  to  know  them,  they  are  accessible 
through  the  assigner 's  on-line  help. 


8.5  SCHEDULE  CREATION  AND  UPDATE  METHODOLOGY 

After  you  issue  the  "Q”  command,  the  assigner  will  create  a 
set  of  schedules  based  on  the  contents  of  the  display  pages  at 
that  point,  and  will  update  the  schedules  in  the  ncjodat.proj j 
relation  to  be  consistent  with  them. 


The  creation  is  done  by  combining  the  information  on  the 
display  page  with  that  in  the  ncjdat.descj  schedule  planning 
factors  relation.  The  basic  task  is  to  create  as  many  schedules 
as  there  are  new-construction-type  jobs  on  the  worksheet,  and  to 
fill  in  the  fields  in  each  such  schedule.  Referring  to  the 


scunple  schedule  record  in  Figure  8-2,  the  assigner  can  deduce  the 
values  for  the  SCENARIO,  CLASS,  YARD,  NCJOBT,  and  JSTYP  fields 
from  what  was  showing  on  the  display.  It  knows  who  you  are  and 
the  current  date,  and  so  can  fill  in  ENTRY_BY,  ENTRY_DATE,  and 
DATADATE.  It  starts  by  assuming  that  AUTONOD  is  always  "YES", 
always  leaves  SHIPNAME  blank,  and  sets  DATASOURCE  to  "assigner". 
It  computes  a  value  for  ANSORDER  based  on  the  order  of  display  of 
classes  on  the  page.  It  deduces  the  basis  date  (say  the  ba&ir^ 
milestone  is  AWARD  for  purposes  of  this  discussion)  from  the 
column  each  assignment  appeared  in. 

This  leaves  the  other  milestone  date  fields  and  some  of  the 
descriptive  fields  to  be  filled  in.  All  but  HULL  are  obtained  by 
drawing  on  planning  factor  information  in  ncjdat.cesc j .  A  sample 
planning  factor  record  is  shown  in  Figure  8-7.  The  assigner 's 
method  is  as  follows.  After  it  has  filled  in  all  the  fields  it 
can  for  a  given  schedule  using  only  the  display's  contents,  it 
looks  in  ncjdat.descj  for  the  most  appropriate  job  descr iption/- 
planning  factor  record.  It  first  looks  for  one  (in  the  current 
scenario)  which  matches  all  of  the  values  for  CLASS,  YARD, 

NCJOBT,  and  JSTYP.  If  it  fails  to  find  an  exact  match  it  tries 
for  a  match  with  a  yard  value  of  "ANY".  If  it  still  can't  find  a 
match  it  tries  for  one  using  a  job  series  type  of  "ORDFCL" 
(ordinary  follow) .  If  this  last  attempt  fails  it  will  stop  and 
require  you  to  enter  the  appropriate  planning  factors. 

Generally  it  will  find  an  appropriate  planning  factor 
record.  Using  the  values  it  finds  there  it  can  immediately  fill 
in  the  COMNUM,  CUSTOMER,  CMETHD,  and  DAYSADDED  fields.  Then  it 
uses  the  specified  intervals  between  milestones  to  compute  the 
rest  of  the  milestone  dates  based  on  the  value  of  the  b^£i^:  cate. 

The  basis  date  will  be  set  to  the  first  day  of  the  period 
v.’hcse  column  the  assignment  appeared  in  on  the  display,  unless 
the  time  units  used  were  fiscal  or  calendar  years.  In  this  case 
the  year  will  be  set  according  tc  the  column,  but  the  month  and 
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Figure  8-7.  Sample  Job  Description  Records  From  Ncjdat.descj 


$LINE  SCENARIO  CLASS  NCJCBT  YARD  JSTYP  ODKMDM  CMEffiD  CUSTOMER 

GOMFLEKGRP  CEFLT  DAYSADCGD  APPROPRWD  AWE6T  SIEL 

Kr.TW  TMnr.  PrrPM  TIWJNT  DATASCORCg  DATADRTE  EMTRYDATE  ENTRYBI 

44  DEMO  LSD-41  NEWOCN  ANY  ORDPOL  1  MC5DULZ  USN 

11/01  0  1  12  6 

20  16  1  MOnnS  908  8/03/1984  8/0^1984  DBA 

45  DEMO  LSD-49  NEWCEN  M?Y  ORDEDL  1  WOJLZ  USN 

11/01  0  1  12  8 

23  24  1  MONTHS  908  8/01/1984  8/02/1984  DBA 

89  DEMO  LSD-49  NO?CCN  ANY  LEAD  1  MDDOLZ  USN 

U/01  0  1  12  8 

23  24  1  MONTHS  908  8/03/1984  8/02/1984  DBA 
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day  will  be  according  to  the  value  o£  the  DEFLTAlvDAY  field  from 
the  planning  factor  record. 


If  you  have  asked  for  date- spreading  by  setting  the  "ADJUST 
MODE"  parameter  on  the  parameter  menu,  this  will  be  done.  The 
algorithm  basically  gathers  up  all  the  ships  to  be  spread,  fig¬ 
ures  the  total  time  over  which  the  spreading  is  to  take  place, 
and  divides  this  by  the  number  of  ships  to  obtain  a  standardized 
interval.  It  makes  up  a  set  of  new  notional  milestones  (for  the 
adjustment  date) ,  recomputes  what  the  display  basis  dates  would 
have  to  be  given  the  planning  factor  intervals,  and  then  checks 
to  make  sure  that  the  new  basis  dates  all  fall  in  the  proper 
periods  (display  columns).  If  any  don't,  it  shifts  things  around 
until  they  do,  attempting  to  keep  intervals  as  even  as  possible. 
The  output  of  the  algorithm  is  a  new  set  of  basis  dates. 


The  assigner  makes  up  new  schedules  for  an  entire  yard  at  a 
time,  and  then  updates  ncjodat.proj j  with  them.  The  actual  up¬ 
date  algorithm  is  complicated,  but  you  can  think  of  it  as  being 
equivalent  to  deletion  of  all  the  old  schedules  (if  any)  followed 
by  addition  of  these  new  schedules,  but  with  two  provisions: 

1)  Schedules  which  were  never  loaded,  i.e.  those  outside 
the  period  dealt  with  in  the  run,  or  those  for  classes, 
yards,  or  job  types  whose  names  were  "off"  in  the 
assigner 's  list  menus,  will  remain  untouched.  If  you 
run  the  assigner,  make  no  chances,  and  go  through  the 
update  step,  the  number  of  schedules  in  ncjodat.proj j 
will  remain  unchanged. 

2)  Schedules  in  the  relation  which  have  an  AUTOMCD  field 
value  of  "NO"  will  be  untouched.  Typically  you  will 
have  set  a  value  to  "NO"  in  the  DBU  after  making  some 
changes  that  you  want  preserved  (if  you  make  changes  and 
don't  set  AUTOMOD,  the  assigner  is  likely  to 
replace/destroy  your  changes  during  your  next  assigner 
run) .  When  the  assigner  finds  such  a  "hard-wired” 
schedule,  it  just  locks  at  its  list  of  newly  created 
schedules,  throws  out  the  one  with  the  basis  date 
closest  to  that  of  the  "hard-wire”,  and  goes  on.  This 
way  the  total  number  of  schedules  and  their  distribution 
over  time  remains  correct. 
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The  assigner  will  delete  "hard-wired”  schedules  if  it 
has  no  new  schedule  for  the  same  job  in  the  same  period, 
i.e.  if  you  have  deleted  all  the  assignments  in  the 
period  the  "hard-wired”  schedule  is  ir. 

Having  updated  the  schedule  relation's  contents,  the 
assigner  must  still  set  the  values  of  the  HULL  field.  It  cannot 
do  this  prior  to  the  update  because  HULL  is  part  of  the 
ncjodat.proj j  unique  key  field  set,  and  an  error  would  result  if 
the  assigner  chose  a  hull  number  for  a  ship  which  was  already 
assigned  to  another  ship  of  the  same  class  whose  schedule  was  of 
the  "hard-wired"  variety. 

The  assigner  attempts  to  assign  realistic  hull  numbers;  in 
order  to  do  so,  it  will  revise  all  hull  numbers  in  ncjodat.  prcjj 
for  the  given  scenario,  not  just  those  for  the  assignments 
loaded,  except  that  it  will  not  change  hull  numbers  of  "hard¬ 
wired"  records.  New  hull  numbers  are  assigned  by  class  in  order 
of  delivery  date,  with  the  number  for  the  ship  with  the  earliest 
delivery  being  either: 

1}  One  plus  the  largest  hull  number  for  ships  of  the  same 
class  appearing  in  the  ncjodat.histj  and  ncjodat.curr j 
relations,  or 

2)  The  number  embedded  in  the  ship's  class  name,  if  any 
(e.g.,  "51"  for  "DDG-51") ,  or 

3 }  One . 

The  set  of  schedules  which  results,  if  loaded  on  a  sub¬ 
sequent  assigner  run,  will  exactly  duplicate  the  pattern  of 
assignments  they  came  from. 
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ALIAS  has  two  tools  for  projecting  the  impact  on  Navy  force 
levels  of  projected  new  construction  and  repair  programs,  the 
Force  Level  Report  Generator  (FLRP)  and  the  Battle  Group  Report 
Generator  (BGRP) .  A  sample  of  the  output  of  the  FLRP  appears  in 
Figure  9-1.  The  report  gives  the  number  of  deployable  ships 
available  to  the  Navy  in  each  of  several  future  periods,  by  ship 
type.  A  sample  Battle  Group  Report  (Figure  9-2)  provides  the 
same  fundamental  information  but  in  a  more  condensed  format, 
computing  the  number  of  deployable  battle  group  units  available. 

To  execute  the  report  generators,  choose  options  2  or  3  on 
the  Command  System's  Force  Level  choice  menu. 

9.1  THE  ALGORITHM 

Both  report  generators  base  their  results  on  the  same  force 
level  computation  algorithm.  This  searches  each  of  the  new- 
construction  type  schedule  relations  (ncjodat.histj ,  ndjodat. 
currj,  and  ncjodat.proj j)  for  records  of  ships  being  commis¬ 
sioned.  For  each  one  found  (in  the  classes  of  interest),  it  then 
searches  the  deact.miscj  for  a  deactivation  date.  If  one  is 
found,  the  ship  is  added  to  the  toted  number  active  during  the 
given  interved.  If  there  is  no  specific  deactivation  date,  a 
standard  service  lifetime,  as  specified  in  the  shlife.miscj 
relation  for  the  ship's  class,  is  used  to  estimate  the  deactiv¬ 
ation  date.  The  estimate  takes  into  account  any  additions  to  the 
standard  life  which  the  ship  may  enjoy  due  to  work  done  in  SLEP 
jobs,  at  reactivation,  etc.  (the  edgorithm  searches  for  such 
jobs)  .  It  also  takes  the  possibility  of  multiple  commissionings 
and  decommissionings  (such  as  have  occurred  for  the  BB-61  class 
ships)  into  account. 

After  adding  the  ship  to  the  number  available  in  each 
appropriate  period,  a  check  is  made  for  any  repair-type  jobs,  for 
example  SLEPs,  which  might  have  temporarily  removed  the  ship  from 
the  deployable  force  level.  If  any  are  found,  the  total  avail¬ 
able  in  the  appropriate  periods  is  decremented. 
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Figure  9-1.  Sample  Force  Level  Report  Generator  Output 
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Figiire  9-2.  Seunple  Battle  Group  Report  Generator  Output 
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The  result  of  the  algorithm  Is  a  table  of  numbers  available 
by  period  and  ship  class  for  the  time  span  you  specify  as  being 
of  interest.  The  FLRP  takes  this  table  and  formats  it  for  output 
according  to  your  instructions.  The  BGRP  uses  the  table  and  a 
set  of  battle  group  "recipes"  you  specify  to  compute  and  format 
battle  group  availabili^. 

Thus  the  data  base  data  which  will  influence  the  contents 
of  these  reports  are  construction^  conversion,  and  reactivation 
schedules  (which  determine  force  additions) ,  schedules  for  some 
types  of  repair  jobs  (which  determine  temporary  force  subtrac¬ 
tions),  and  deactivation  dates  and  standard  service  lives  (which 
determine  permanent  force  subtractions  (or  perhaps  temporary  ones 
in  the  case  of  mothballings) .  The  reports  will  thus  immediately 
reflect  changes  which  you  make  to  projected  new  construction 
programs,  and  can  also  be  used  to  study  the  impact  of  SLEP  pro¬ 
grams  and  changes  in  service  lives  due  to  improved  maintenance 
cycles. 

In  addition  to  the  raw  data  in  the  data  base,  you  have  two 
"handles"  with  which  to  control  the  contents  and  format  of  the 
reports.  The  first  is  the  settings  of  the  Command  System's  Force 
Level  parameters;  the  second  is  the  contents  of  report  format 
control  files. 

9 .2  PARAMETER  OPTIONS 

Figure  9-3  shows  a  sample  Force  Level  parameters  menu.  The 
effect  of  the  settings  is  as  follows: 

1)  KEEP  REPORT  ON-LINE:  The  reports  will  appear  on  the 
printer  you  specify  in  the  User  Environment  Parameters 
menu,  but  by  setting  this  pareuneter  to  "YES"  you  can 
also  have  them  saved  into  a  disk  file.  You  can  then 
edit  the  disk  file  to  make  minor  format  modifications. 
They  will  be  saved  into  a  file  called  "FLREPT"  in  your 
log-on  group. 

2)  REPORT  START  DATE:  The  start  date  of  the  period  you 
wish  the  report  to  cover.  This  date  should  be  the  first 
day  of  a  period;  if  it  is  not,  it  will  automatically  be 
set  back  to  the  first  day. 


Figure  9-3.  Commauid  System  Peureuneter  euid  List  Menus 
Serving  the  Force  Module 


Menu  is  FLPEFT  *  ALIAS  QOItlAND  SY51SM  *  Scenario  is  DEMO 

FORCE  LEVEL  MID  BATILEGRODP  REPORT  GEMERATOR  PARAMETERS 

1.  KEEP  REPGRT  CX9-LINE  «  YES  (YES^ND) 

2.  REPORT  START  DATE  «  1/  1/1986  (MJVWYYYY) 

3.  REPORT  HJD  DATE  =  12/31/2005  (m/DD/mY) 

4.  RETIRE  SHIPS  BY  «  LIFE  (LIFErDATE) 

5.  TDC  FBUOD  LENGTH  «  CALYR  (DAYrWEEK,MCNTH,QTErCALYR) 

6.  IN  FORCE  DAY  *  END  (BEGIN, Q1D) 

7.  PROGRAM  NILESTCNE  «  APFROP  (APFROP,AfD,DQJV) 

8.  ODT  OP  EORCE  REPAIR  JOBS  -  LIST  (ALI/LIST) 

OOMIAND: 


Menu  is  FLREPT  *  ALIAS  OOMIAND  SYSTEM  *  Scenario  is  DEMO 

REPAIR  JOBS  THAT  RQCVE  A  SHIP  FROM  FORCE  DURING  EXEODTIGN 

1.  REFUEL  3.  *  SLEP 

2.  REPAIR  4.  TESTRE 


OOMAND 


3)  REPORT  END  DATE:  The  last  day  of  the  period  you  wish 
the  report  to  cover.  Note  that  due  to  printer  width 
limitationsr  the  maximum  duration  a  report  can  cover  is 
20  periods.  If  you  ask  for  more,  the  end  data  will  be 
set  back  to  give  a  20  period  duration. 

4)  RETIRE  SHIPS  BY:  This  allows  you  to  control  how  the 
2dgorithm  determines  retironent  dates.  If  DATE,  it  use 
a  deactivation  date  for  a  given  ship  if  it  can  find  one. 
If  LIFE,  it  will  use  the  deactivation  date  only  if  the 
date  is  prior  to  the  date  of  the  run  (i.e.  the  ship  has 
already  retired) .  ^is  parameter  can  be  useful  for 
studies  in  which  you  want  to  assess  the  effect  of  a 
wholesale  change  in  service  lives;  it  makes  it 
unnecessary  for  you  to  change  the  deactivation  dates  for 
currently  active  ships  one  at  a  time. 

5)  TIME  PERIOD  LENGTH:  Duration  a  report  column 
represents.  Used  in  combination  with  the  start  and  end 
dates  to  determine  the  number  of  columns  appearing  on  a 
report. 

6)  IN  FORCE  DAY:  Most  ships  will  retire  in  the  middle  of  a 
given  period;  there  must  be  a  convention  for  deciding 
whether  a  ship  is  or  is  not  to  be  counted  in  the  force 
during  that  period.  Ohere  are  two  choices  for  the 
convention:  if  BEGIN  a  ship  is  counted  in  the  force  if 
it  was  active  on  the  first  day  of  a  period;  if  END  it  is 
counted  only  if  active  on  the  last  day  of  a  period. 

7)  PROGRAM  MILESTONE:  Notice  in  Figure  9-1  that  the 
numbers  of  deployable  ships  are  broken  out  into  the 
categories  of  "inventory”  and  "program".  You  have  the 
capability  to  break  down  the  numbers  of  each  ship  type 
available  into  up  to  five  separate  categories  on  the 
basis  of  their  date  of  entry  into  the  force.  This 
allows  you  to  assess  the  effect  of  different  parts  of  a 
construction  program  (e.g.,  a  POM  and  an  EPA)  with  more 
precision.  This  parameter  specifies  which  ship 
construction  milestone  is  to  provide  the  basis  date  for 
determining  which  category  a  ship  falls  into. 

8)  OUT  OF  FORCE  REPAIR  JOBS:  This  parameter  is  a  gate  to  a 
list  menu,  also  shown  in  Figure  9-3,  which  contains  the 
names  of  repair  job  type  codes.  Those  jobs  which  are 
"turned  on"  in  the  list  menu  will  be  considered  by  the 
force  computation  algorithm  to  remove  a  ship  temporarily 
from  the  force  while  they  are  being  done. 

9.3  REPORT  CONTROL  FILES 

In  the  sample  reports,  ship  types  and  battle  groups  appear 
in  a  particular  order.  You  have  control  over  this  order  and  over 


which  ship  classes  are  part  of  each  type,  and  which  can  help  make 
up  each  kind  of  battle  group.  You  exercise  this  control  by 
providing  the  report  generators  with  a  format  control  file  speci¬ 
fying  what  you  want  done.  These  files  required  for  report  gener¬ 
ator  operations. 

The  files  contain  commands  and  data  vedues.  There  are  two 
types  of  file  (i.e.  two  different  sets  of  commands)  r  one  for  each 
kind  of  report. 


A  sample  report  control  file  suitable  for  FLRP  appears  in 
Figure  9-4.  The  file  contains  three  kinds  of  linesr  none  of 
which  may  exceed  72  characters  in  length: 

1)  COMMENT  LINES:  These  are  lines  which  begin  with  a  ”%”. 
They  are  ignored  by  FLRP.  You  may  type  comments  and 
notes  to  yourself  on  these  lines  to  remind  yourself  of 
your  rationale  for  the  file's  contents.  FLRP  will  also 
ignore  blank  lines. 

2)  COMMAND  LINES:  These  begin  with  one  of  the  nine  valid 
keywords,  and  typically  have  additional  information 
following  the  keyword  such  as  ship  class  names  and 
labels  which  are  to  appear  on  the  printout.  Such 
information  must  always  be  separated  from  the  keyword  by 
one  or  more  spaces.  If  there  are  multiple  speci¬ 
fications,  e.g.  multiple  class  names,  they  must  be 
separated  from  each  other  by  commas. 

3)  CONTINUATION  LINES:  These  begin  with  a  and 

indicate  to  FLRP  that  you  could  not  fit  all  the 
information  you  needed  to  onto  the  previous  keyword 
line. 

The  valid  keywords  and  their  meanings  are: 

PRGLB  Stands  for  "program  label  specification”.  Following  the 
keyword  a  label  to  appear  on  output  and  a  date  in 
MM/DD/YYYY  format  are  required.  All  ships  whose  "program 
milestone"  (see  the  discussion  of  parameters  in  the 
previous  section)  is  after  the  given  date  but  not  before 
the  date  given  on  the  ^lexl;  PRGLB  line  (if  any)  will  appear 
on  the  report  on  lines  having  the  given  label.  PRGLB  lines 
must  be  the  first  commands  in  the  file,  and  must  appear  in 
the  order  of  their  dates.  They  are  how  you  break  out  force 
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Figxjre  9-4.  Scunple  Force  Level  Report  Format  Control  File 


%  THIS  IS  A  FORCE  LEVEL  REFOBT  FORMAT  CONTROL  PILE 
%  ANY  LINE  BIX3INNING  WITH  %  IS  GONSIOERED  A  NOTE  AND  IGNORED 

% 

%  TTte  next  two  lines  tell  ELRP  to  qplit  the  force  level 

%  into  tvo  lines  for  eadi  class,  based  on  ship  approp  date 

PHGIfl  Inventory  ,1/1/1900 

FRGEB  Rrogrm  ,10/1/1986 

% 

%  The  TITLE  lines  give  the  title  that  will  be  printed 

%  (centered)  on  the  top  of  each  report  page 

TITLE  FOM  86  Force  Impact  Projection 

TITLE  Based  on  Standard  Service  Lives 

TITLE  (All  Data  Noticnal) 

% 

%  Start  the  report  specification.  EfIOT  lines  tell  ELRP  to 
%  start  keeping  a  running  total,  ETOT  where  in  the  bod^ 

%  to  print  the  total;  last  two  words  on  ETDT  lines  are 

%  the  left  and  ri^t  labels  actually  printed.  Label 

%  on  BTDT  line  and  first  one  on  ETDT  for  internal  FLRP  use. 

%  EITDT  is  like  ETDT  except  specifically  designed  for 
%  subtotals;  it  ensures  no  page  feed  happens  in  the 
%  middle  of  a  type  being  printed. 

%  TYPE  lines  specify  ship  t^s  by 

%  giving  the  names  of  all  the  classes  in  the  type. 

START 
BTDT  grand 
BTDT  subn 

TYPE  SSBN,  SSBN-726,SS&N-€40,SSBN-€27,SSN-€16, 

+  SSBN-611,S£EN-610,S£EN-609,S£BN-601,SSBN-599, 

+  SSBN-598 

ETDT  subn,SSBN,TDTAL 
BTDT  sub 

TYPE  SSN,  SSN-688,SSNX,SSN-21,SSN-575,SSN-578,SSN-585,SSN-594, 

+  SSN-5g7,SSN-637,SSN-«71,SSN-685 

EIDT  sub  , SSN, TOTAL 
% 

%  note  job  line  causes  carriers  in  SLEP  to  be  printed 
%  they  do  not  appear  in  the  deployable  total 
BTDT  carrier 
BTDT  dcarrier 

TYPE  C7,  CV-41,C>-59,CV-€3,CV-€7 

TYPE  CVN,  CVN-65,CVN-68 

Error  dcarrier,CARRIER,EePLCfYABLE 

JOB  CV,  IN  SLEP, SLEP,  CV-41,CV-59,CV-63,CV-67 

EIDT  carrier,  CARRIER,TDTAL 
% 

BTDT  bb 

TYPE  BB,  BB-61 

ETDT  bb,  BB,  TOTAL 


Figure  9-4.  Sample  Force  Level  Report  Format  Control  File 


% 

BIDT  cruisers 

TYPE  OGN,  GGN-25,OGN-36,QQN-38,GGN-35,GGl}-9 

TYPE  OG,  CG-16,OG-26,OG-47 

EniDT  cruisers, 

% 

BTOT  ddg 

TYPE  DCG,  EDG-2,M3G-37,DO&-51,DDG-993 

ETCT  ddg,  EDG,TDTAL 

% 

BTOT  dd 

TYPE  DD,  DD-945,DD-963 

ETOT  dd,  ED,  TOTAL 

% 

BTOT  frigate 
BTOT  ff g 

TYPE  FPG,  FPG-l,FPG-7 

ETOT  ffg,  FFG,  TOTAL 

BTOT  ff 

TYPE  FF,  FF-1037,FE^1040,FF-1052 

ETOT  ff,  FF,  TOTAL 

Error  frigate,  frigate, total 
% 

BTOT  amphibs 

TYPE  AMIHIBS,  IflD-X,rSD-41, LSD-49 ,LCX:-19,IflA-l,LBD,LHI>-l, 

+  LKA-113,LPl>-l,LPD-4,LIH-2,LSD-28,LSD-36, LSD-41, 

+  LSD-49 ,LST-117 9 

ETOT  amphibs,  AMPHIBS, TOTAL 
% 

BTOT  mine 

TYPE  MINE  CM,  Naf-l,MSH-l,MSO-422,KES 
ETOT  mine,  MINE  SHIPS, TOTAL 
% 

BTOT  aux 

TYPE  AOXILIARY, AD-37, AD-41  ,AE,AE-21,AE-23  ,AE!-26,AF-58,AFDH, 

+  AFS-l,i^,AK-286,i^l43,AD-177,AD-187,AO-51, 

+  AOE,  AOEhl  ,AOR-l  ,AR,  AREH-4  ,ARS-50 ,  AS-19  ,AS-31  ,AS-33 , 

+  AS-36,AS-39,ASR-21,A!IP-166,ATS-1 

ETOT  aux,  AUXILARY, TOTAL 

% 

BTOT  T-SBIPS 

TYPE  T-SHIPS,  T-A(CS,1VAG,T-AG0S-1,T-AD-187,TVARC-7,T-AVB,TAG0S-1, 
+  TAH-X,TAO-187 

ETOT  T-SHIPS,  T-SHIPS,  TOTAL 


availability  by  program  source;  note  in  the  sample  in 
Figure  11-4  that  all  ships  appropriated  before  fiscal  1987 
will  be  classes  as  inventory  shipsr  while  all  appropriated 
later  will  be  classed  as  PON  ships. 

TITLE  These  lines  must  appear  after  the  PRGLB  lines  but  before 
any  other  keyword.  Ibey  are  used  to  specify  the  report's 
title,  which  will  be  centered  over  the  body  of  the  report. 
Up  to  five  are  allowed,  and  you  may  specify  blank  TITLE 
lines  to  leave  blank  lines  in  the  title  text. 

START  FLRP  will  ignore  any  keywords  which  occur  before  a  START 
line,  or  which  appear  after  a  STOP  and  before  the  next 
START.  This  allows  you  to  make  up  a  large  standardized 
report  control  file  and  then  use  parts  of  it  selectively. 
For  example,  if  you  did  not  want  information  on  carrier 
availability  to  print  out,  you  could  place  a  STOP  line  just 
before  the  section  of  the  file  dealing  with  carriers,  and  a 
START  line  right  after  it.  It  is  not  necessary  to  delete 
lines  from  the  control  file  to  effectively  remove  them. 

STOP  Used  in  conjunction  with  START.  Any  lines  read  after  a 
STOP  is  encountered  but  before  the  next  START  will  be 
ignored. 

TYPE  This  is  in  some  sense  the  most  important  keyword.  TYPE 

lines  give  the  label  for  a  section  of  FLRP  output,  followed 
by  a  list  of  ship  classes  whose  availability  is  to  be  added 
up  to  give  the  availability  figures  for  that  section  (where 
a  section  is  defined  as,  e.g.,  the  program  and  inventory 
lines).  In  the  sample  file,  it  is  specified  that  on  the 
output  classes  CVN-65  and  CVN-68  are  to  be  lumped  together 
under  the  label  "CVN".  You  may  specify  as  many  or  as  few 
classes  per  type  as  you  desire.  However,  it  is  very 
important  that  you  specify  only  valid  class  names  for  your 
scenario.  The  computation  algorithm  logic  is  such  that  it 
will  simply  ignore  any  invalid  class  names,  perhaps  then 
giving  you  results  which  do  not  include  all  the  classes  you 
think  they  do.  The  order  of  the  TYPE  lines  in  the  file 
controls  the  order  in  which  their  corresponding  sections 
will  appear  on  the  report. 

JOB  This  keyword  lets  you  have  the  number  of  ships  undergoing  a 
given  repair  job  appear  on  the  report.  The  syntax  of  the 
line  is  "keyword  label  job_type_code  class_list".  The 
label  will  appear  on  the  report;  the  job  type  code  tells 
FLRP  which  job  you  mean;  and  the  class  list  which  classes 
you  wish  totalled  on  the  report  line.  Ihe  most  common  use 
of  the  keyword  is  to  provide  a  tally  of  the  number  of 
carriers  in  SLEP,  in  combination  with  a  parameter 
specification  which  says  that  ships  undergoing  SLEP  are  to 
be  considered  undeployable.  Itie  deployable  carriers  figure 
and  the  in-SLEP  figure  can  then  be  combined  to  arrive  at  a 
figure  for  total  carriers  in  each  period. 


BTOT  Stands  for  "begin  totaling",  and  must  be  followed  by  a 
total  name.  The  command  causes  FLRP  to  establish  a 
totaling  buffer  line  to  which  the  contents  of  all  TYPE  and 
JOB  sections  are  added  until  processing  encounters  an  ETOT 
or  EITOT  line,  at  which  point  the  total  is  printed.  By 
placing  a  BTOT  before  a  TYPE  line  and  an  ETOT  following  it, 
you  can  have  the  inventory  and  program  lines  added  up  on 
the  output  to  provide  a  total-deployable  measure  for  the 
TYPE.  The  commands  can  likewise  be  used  to  for  computation 
of  more  extensive  subtotals  and  for  grand  totals. 

ETOT  Stands  for  "end  totaling".  Must  have  a  total  name  which 

matches  a  name  on  a  previous  BTOT  line.  If  any  other  BTOT 
lines  were  given  between  that  BTOT  and  this  ETOT,  they  must 
have  matching  ETOT's  before  this  one  as  well  (i.e.  BTOT*  s 
and  ETOT's  can  be  nested,  but  the  nesting  must  be  strict). 
After  the  name  two  labels  must  appear,  one  for  the  report's 
far  left  label  column  and  one  for  its  right-hand  label 
col umn. 

EITOT  Stands  for  "end  internal  total".  This  has  the  same  effect 
as  ETOT,  but  forbids  page  breaks  from  occurring  (FLRP  will 
start  a  new  page  only  following  an  ETOT  line;  if  necessary 
it  will  move  an  entire  section  onto  the  next  page) . 

When  constructing  an  FLRP  format  control  file,  keep  in  mind 
that  the  order  in  which  the  keywords  appear  in  the  file  matters. 
In  general,  the  order  should  be  PRGLB's,  TITLE'S,  and  START's, 
followed  by  sets  of  BTOT' s,  TYPE'S,  JOB'S,  and  ETOT's  or  EITOT' s. 
Publicly  available  format  control  files  are  stored  in  the  .fmtfiJ 
group.  Hie  sample  file  discussed  here  is  stored  in  that  group; 
you  may  use  it  as  a  basis  for  any  you  contruct. 

9.3.2 

A  sample  format  control  file  suitable  for  BGRP  appears  in 
figure  9-5.  It  is  similar  in  basis  outline  to  those  for  FLRP, 
being  composed  of  comment  lines,  keyword  command  lines,  and 
continuation  lines.  The  keywords  are  not  the  same,  however, 
since  they  support  a  different  logic. 


BGRP  expects  you  to  define  a  set  of  kinds  of  battle  group 
which  the  Navy  desires,  along  with  a  target  number  for  each  kind. 
It  also  expects  you  to  tell  it  what  sorts  of  ship  can  be  used  to 
make  up  each  group,  along  with  recipes  of  the  mixtures  required. 
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Figvire  9-5.  Sample  Battle  Group  Report  Format  Control  File 


%  ALIAS  BATILE  GROUP  REPORT  FCRM^/CCNTOnS  DEFINITICN  FILE 
%  format  is:  title;  start;  type;  function;  bgro(q>;  makeup;  end 
%  title  line  has  titles  for  report 
%  start  line  indicates  start  of  processing 
%  type  line  indicates  ship  classes  making  up  a  type 
%  function  line  lists  types  which  can  perform  a  functionr  in 
%  order  of  preference 

%  bgroup  describes  battle  groups  to  be  made  ip 
%  makeup  describes  which  functions  each  battle  group  requires 
% 

TULE  Deployable  Battle  Group  Projection  For  on  POH-86 
TI^HjE  Based  on  Surface  Combatant  Requirements  Only 
TITLE  (All  Data  Notional) 

% 

SIART 

%  type  format  similar  to  force  level  report:  namer labels class  list 
% 

TYPE  CARRIER,  CARRIER,  CV-41,CV-59,CV-63,C7-€7,CVN-65,CVb}-68 
TYPE  BB,  BATTLESHIP,  BB-61 

TYPE  CRUISER,  CRUISER,  aGN-25,aaJ-36,GGN-38,OGN“35,OGN-9,a5-16,OG-26,GG-47 
TYPE  nX3,  EDG,  EDG-2,CDG-37,EDG-51,EDG-993 

TYPE  DD,  ED,  EO-945, 135-963 

TYPE  FPG,  EFG,  ETG-l,FPG-7 

TYPE  FF,  FF,  FP-1037,P5^1040,PP-1052 

% 

%  function  format  is  name,  list  of  types  which  can  perfom  it 
%  in  order  of  preferoice 
FUNCnCN  CRUISER,  CRUISER,  BB 
EUNCnON  CARRIER,  CAPPJER 
FUNCTION  EDG,  EDG,  CRUISER,  BB 
FUNCTION  DD,  DD 

FUNOnON  FRIGATE,  FFG,FF 
% 

%  bgroup  fonnat  is  name,output  label, priority, target  level, 

%  begin  date  this  defn  takes  effect,  end  date  this  defn  effective 
BGROUP  CVBG,CARRIER  BG,1 ,17 ,1/1/1900 ,1/1/2111 
BGROUP  SAG, SURFACE  AG,  3,  4, l/Vl 900, 2/1/2111 
BGROUP  MAF,FftRIFIE  AF,  2  ,  2,1/1/1900,1/1/2111 
BGROUP  ESC, SUPPLY  ESOORT,4, 10, 1/1/1 900 ,1/1/2111 
BGROUP  CEN, CONVOY,  5,10,1/1/1900,1/1/2111 
% 

%  maketp  fcrma't  is  battle  group  name,  function,  #  reqd,  func,  #reqd 

MAKEUP  CVBG,  CARRIER,1,CRUISER,1,EDG,4,ED,2,FRIGATL,4 

MAEKUP  SAG,  CRDISER,2,DDG,2,FRIGATE,2 

MAKEUP  MAF,  CRUISER,2,EDG,2,ED,4,FRIGATE,10 

BGROUP  ESC,  DOG,l,DD,l, FRIGATE, 2 

BGROUP  CON,  ED,1, FRIGATE, 4 


The  recipes  are  called  MAKEUPS;  they  are  composed  of  ship 
FUMCTIONSr  which  can  be  performed  by  one  or  more  ship  TYPES,  and 
the  TYPES  are  in  turn  made  up  of  one  or  more  classes. 

Given  this  information  and  the  table  of  per-period  avail¬ 
abilities  by  ship  class  produced  by  the  basic  force  computation 
algorithm  (see  Section  9.1),  BGRP  attempts  to  fill  the  battle  • 
groups  in  each  period  out  of  available  ships  and  in  priority 
order.  Its  method  is  to  treat  one  period  at  a  time,  and  to 
"build*  battle  groups  of  the  highest  priority  until  it  either 
hits  the  target  for  that  battle  group  or  runs  into  a  shortage. 

It  then  goes  on  to  the  battle  group  next  in  priority.  When 
searching  for  ships  which  can  perform  a  given  FUNCTION,  it  will 
use  draw  from  TYPES  in  the  order  in  which  they  are  named  on  the 
FUNCTION  line  in  the  file,  so  TYPE'S  should  appear  on  those  lines 
in  the  order  of  their  appropriateness  for  fulfilling  the 
function. 


The  keywords  are: 

TITLE  Similar  in  function  to  the  TITLE  keyword  in  FLRP  files; 
you  can  use  it  to  specify  up  to  five  lines  of  report 
title  text,  which  will  be  centered. 

START  The  role  of  these  keywords  is  identical  to  the  one  that 

STOP  they  play  in  FLRP  files.  See  the  preceding  Section. 

TYPE  These  group  ship  classes  into  ship  types.  Following  the 

keyword  must  be  the  name  of  the  type,  a  label,  and  then 
the  list  of  classes  belonging  to  that  type.  As  with 
FLRP  files,  if  the  class  list  is  too  long  for  one  line, 
it  may  be  continued  on  the  next  line  by  placing  a  "-t-"  in 
the  first  column.  The  label  is  used  in  the  "BALANCE” 
section  of  the  report,  which  gives  the  number  of  ships 
of  each  type  remaining  after  BGRP  has  done  its  best  to 
make  up  the  battle'  groups. 

FUNCTION  These  lines  define  functional  categories  of  ships,  and 
are  the  terms  in  which  battle  group  recipes  are 
specified.  Following  the  keyword  must  be  a  name  for  the 
given  function  and  then  a  list  of  type  names,  as  defined 
on  previous  TYPE  lines. 
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BGROUP  Battle  GROUP  lines  define  the  battle  groups  to  be  made 
upr  one  per  line.  The  format  of  the  specification  is 
"keyword  group,  name,  group.labelr  tar  get.  number, 
target,  effective,  date,  tar  get.  end.  date".  The  label  will 
appear  on  the  report,  marking  the  line  for  the  given 
group.  Note  that  the  groups  appear  on  the  report  in  the 
order  in  which  they  are  specified  in  the  file.  They 
target  number  is  effective  during  the  period  specified 
by  the  dates.  It  is  permitted  to  have  more  than  one 
line  for  a  given  battle  group  (they  must  have  the  same 
name  so  they  can  be  associated)  in  order  to  change  the 
target  sometime  during  the  report  period. 

MAKEUP  These  lines  give  the  recipes  for  each  battle  group,  one 
line  per  group.  The  name  of  the  battle  group  being 
defined  must  appear  immediately  after  the  keyword  (it 
must  have  been  defined  by  a  previous  BGROUP  line) . 
Following  this,  pairs  of  "function,  number"  must  be 
specified,  each  of  which  indicates  that  the  given  battle 
group  requires  that  number  of  that  function. 

The  keywords  must  appear  in  a  strict  order  in  BGRP  format 
control  files:  all  TITLE  lines,  followed  by  all  TYPE  lines, 
followed  by  all  FUNCTION  lines,  followed  by  all  BGROUP  lines, 
followed  by  all  MAKEUP  lines.  START  and  STOP  lines  can  be  used 
to  "disconnect"  other  lines,  but  you  must  be  careful  not  to  dis¬ 
connect  any  lines  which  are  implicitly  required  by  lines  farther 
down  the  file  (unless  you  disconnect  those  lines  as  well)  . 


